Do you need to know C++ to develop software. I'm an advanced PC user. Is it pretty easy to pick up. What kind of capabilities can I tap into? Thanks.

There are many, many different programing languages. The one you learn depends on what your end goal is, and to an extent, your level of commitment to programming in the first place.

No, you don't need to know C++ to develop software. C++ is just one of the many programming languages and C++ is arguably the most complex one to learn, but it provides some middle ground between close-to-best performance of the software and easiness of keeping the code structured and relatively not-too-long development time.

There are so many others: python, perl, ruby, php, C, assembly, erlang, ocaml, java, javascript, objective C, basic, bash, ksh, lisp, fortran, cobol, and many others I forgot...

In general it is not very easy to pick up programming. You'll need to read, learn, experiment and try a lot.

Some programming languages are more difficult to learn, but will give more/other possibilities, or better performance. What also matters is how important it is that the software can run on different operating systems easily.

Much depends on what kind of software you want to develop. Many languages can be used to do develop pretty much anything. But there are some things you really would not use a certain language for. For example to develop system tools or an operating system, your pretty much limited to C or C++. But you would not use C or C++ to make a web application (though not impossible, it is very impractical and not recommended to say the least).

The most well-known "middle ground general pupose languages" are (IMHO): python, perl, ruby and java.

I think there's not much more to say about it without a more specific question.

I am not a programmer, but that does not stop me from opinionating.....

I would not start with an Object-oriented language. If you have already struggled through learning how to program typical applications, then the advantage of OO maybe makes more sense. (Even though I have done some of those struggles, OO still is not 100% intuitive----I can't imagine learning it before learning the basics.)

I don't really want to push this into another nobody convinces anyone to change their mind argument, but even the question of the original post indicates "just one of the many" is misleading.

There are many other programming languages. C++ is the most effective for large projects, for projects where performance is important and for many other situations.

There are many and C++ is one, but it stands out in too many ways to be accurately described as "just one of the many".

C++ does not approach the "best performance" that can be achieved by a really good assembler programmer programming really carefully. But that describes a form of programming that is almost non existent now (and for good reason). So "middle ground" is misleading. It is a middle ground between a high efficiency that doesn't really exist and the low efficiency of other languages. Among languages people actually use, C and C++ are at the high extreme of efficiency. In a very complex project, when coded by an expert, even more efficiency is practical in C++ than C (but more often there is no significant efficiency difference between them and bad programmers often write C++ code that is much less efficient than similar C code).

C++ would be a very nice language for a web application. It would be an unusual choice, and has certain disadvantages (less relevant online help, etc.) just from being an unusual choice. But web development really isn't specialized enough to require something different from C++.

I don't know ruby at all. I have done significant maintenance and enhancements of software others have written in Python and Java (far less in Perl). That experience made me really like Java as an alternative to C++ in many situations and really hate Python in all situations. I don't think Python fits any real need. With less certainty, I also think Perl is worthless.

I disagree. As soon as your project is big enough to need any kind of structure, you are probably dealing with problems for which OO is the best structure. It is the best form for a beginner to make the key steps from barely above trivial to medium complexity.

The way Java handles OO does add a little overhead to the very first step from nothing up to trivial. The best way to deal with that is the "boilerplate" concept. You copy some of the beginning stuff from a tutorial or other simple example and just use that basic wrapper without any need to understand it. That is actually a normal way people learn most things: Copy the parts you don't understand.

If you first learn to program (as I did) in non OO languages, the switch to OO can seem very counterintuitive. I don't think that would happen if you started with an OO language. Nothing you must do in programming is really intuitive, but OO is no less so than other concepts and for simple problems OO is easy to apply and provides useful organization.

When you get into much more complicated projects, OO ought to be reduced to just one of many approaches to structuring. OO languages, including Java and C++ are designed by people who clearly assumed that OO is always the most important structuring tool. So things will get inconvenient in any OO language when the problem doesn't fit. But (especially in C++) there are ways around that problem. It is more often coding standards in an organization or project that make it too hard to get around OO, rather than the language itself.

I started learning programming with BASIC 2.0 on the Commodore VIC-20 in the spring of 1981. I soon moved on to 6502 Assembly in a misguided quest to create my own video games. I also picked up bits and pieces of several other languages so outdated that I can't even remember them.

Later in life, I started studying C. It wasn't until I went back to school that I seriously began to learn it. C is very different from those old languages, and I still have a great many bad habits to break. (I tend to write compact, obscure code that doesn't work well due to my prior conditioning in tight memory constraints.)

After C, I began to tackle Javascript, Java, and a few others. I've successfully completed working programs in all these languages, with some effort. (I've never successfully completed a C++ program, since I can't get beyond Hello World.)

All these languages have their on quirks, strengths, weaknesses, and preferred tasks. It doesn't matter much which one you start with, as long as you start. Many concepts carry over quite well from one to the next, so most differences come down to how you access libraries or objects.

My recommendation is this. If you decide to master only one language to the exclusion of others, make it C. C is relatively simple compared to the rest, and there is an overabundance of help and tutorial information both on the web, and in your own public library. All the fundamental concepts of programming can be learned in C relatively quickly. Once you learn to do something in C it is quite easy to do it in another language, though you still need to be aware of small differences.

So after you feel you've mastered C, you'll want something more powerful and sophisticated. Then I'd recommend Java be your next step.

Alas, "OO-only" seem to be quite "bone-headed". For example, it's almost impossible to make them grasp functional languages cocepts (especially the Java folks).

Ironically, C++, being itself an imperative (opposed to functional) language has its template system implemented in a functional manner.

OCaml is both functional and imperative with clear separation of the two.

OO as a whole - what about circle vs ellipse problem ? I.e. how intuitive can it be in an OO language ?

I haven't seen any discussion before of "circle vs. ellipse" illustrating a flaw in OO concepts, but I think I can guess your point.

In OO hierarchies, you are supposed to have base classes representing the concepts that are all of
more general
less complex
less information
vs. derived classes representing concepts that are
more specific
more complex
more information

I have interacted with a lot of OO fanatics who insist that any time the problem doesn't fit OO you must have misunderstood the problem, and by using OO strictly you are then getting the extra benefit that it forces you to correct your understanding of the problem. (I've been surprised at how few OO fanatics jump into threads like this. In professional programming, they are very common).

I think your point about circle vs. ellipse is that in mathematics an ellipse is the more general concept and a circle is a special case of an ellipse. But in programming, you would want to recognize the fact that the circle is less complex and needs less information.

So a bedrock principle of OO (less complexity and information in the less specialized classes) is in fact often wrong.

In cramming circles and ellipses into an OO hierarchy, you would probably want the base class to be some kind of "round thing" concept whose default behavior would be circle, while ellipse would be the derived class. It would be much uglier and less efficient to make the general case ellipse be the base class and the special case circle derived.

Either way, it would be cramming concepts into a structure where they don't quite fit. Those situations really don't bother me in an OO language, because the code still ends up pretty clean. The cases where an OO approach really messes up a project tend to be much more complex and I don't know any way to illustrate them with simple ideas.

You have exactly guessed what I mean.

To put it shortly, intuitive expectations from (the former USSR) school geometry (first define/study/explore/describe ellipse, then use circle as a corner/sub case) are exactly opposite to the OO expectations (define first circle as base class, then extend it to become ellipse).

The basic value/goals are, however

1. robustness/reliability;
2. easy reuse;

.

OO is just a way to achieve the above values/goals - sometimes good/easy, sometimes ugly to the extent it defeats the purpose.

Modern OO languages often complicate things. For example, a typical Java interview question is which of a number of methods with the same name will be called for a given set (of types) of input arguments.

On the other hands, the same Java proponents fiercely oppose my favorite closures in a piece of code like this (Perl):

Both things (reuse of method name, reuse of variable name) have the goal of easy (?) extensibility/inheritance.

The funny thing, again, is bias. And unwillingness to accept in general "there is more than one way to do it" principle.

What would be wrong to make a circle-class inherit from an ellipse-class if that fits your needs. The circle being a specialized case of the ellipse where both fixed points are the same?

It's not inheritance in OO sense.

If you have ellipse class you do not need circle in the first place. Just always use r1 == r2 for ellipse, and you get circle.

You do not need an extra data member for circle; if you do not want to pass explicitly r1, r2, but just r, write wrapper functions - the latter do not need to belong to any class.

In OO inheritance is extension, in case of ellipse -> circle it's "truncation"/simplification (r1 == r2).

Learning C would be good start. And C++ is a superset of C. The linux kernel and most of the base system packages are written in C.

Heh... here we go again... everyone will chime in with an opinion on their own favourite language and how it's the best for x, y and z.

How I see it is that someone starting out should begin with a language that is easy to learn, and that gets out of your way rapidly so you can start to learn the concepts or being a programmer. Not a C programmer, or a Java programmer, just a programmer.
There are concepts that are common to all languages... the ability to abstract something into a data type, the ability to reduce a problem to discrete steps... regardless of whether your particular Favourite Language happens to be PDP8 assembly or Ruby.

This is why the primary CS text book at MIT is still "Structure and Interpretation... " by Gerald Sussman. It uses Scheme as its instructional language because Scheme doesn't impede the learning process with the complexities of the language itself. No strong typing, no buffer over-runs, no multiple-inheritance spaghetti... just a language that will allow you to get on with the job of learning to code.

These days, the languages that seem to fit this role best are Ruby and Python. They are both interpreted, which eliminates that whole edit->compile->execute cycle, and eliminates the library and binary format hell that so many compiled and semi-compiled languages are prone to. Sure, neither is going to be used to write the next microkernel or best selling game, but they are both highly useable... Twitter, for instance is written in Ruby, Google use Python as their in-house R&D language, and they have a pretty shallow learning curve and no weird abstractions to frighten you. When you get to a level where they are no longer useful, you will be well qualified to decide where to go next, and not have anything to fear from what is waiting for you in the dark recesses of other languages.

My 2 cents.
If you wish to develop a program using the qt or kde frameworks, then you will want to use C++. If you wish to develop for the gnome desktop, then use C or C++. If you are new to programming, Python is a good learning language. IMHO, Python is the new Pascal, which used to be the language of choice (other than Fortran for engineers) for a first language.

Besides programming, don't forget to learn bash. If you want to transistion from an "advanced PC" user to an advanced Linux user, you will want to become handy using many of the utilities such as grep, sed, awk, sort, etc. and pipe them together to do things you may have never imagined possible on a PC.

Good Luck!

It depends but what I can just tell is just try to have fun while you learn. Or perhaps don't take things too seriously? What I mean is if you start a project, do you have to *perfectly* finish it until the end? That's what I'm doing now and it's painful I tell you. Avoid such mistakes if you can.