How's C++?

[Sam-U-Rai]

I'm currently taking BASIC for the first half of the year this semester of HS and was wondering what the next half aka C++ will be like?

I find BASIC to be kinda easy once you get the main ideas down (Dim your variables, equal them, answer them in labels, if then statements, just a few of the things I know so far in experience)

[blue60007]

Once you get the concepts of programming (in general) down (ie, input/output, logic, etc) learning a new programming language is mostly learning the syntax of the language. If you're comfortable with the concepts of programming you shouldn't have too much trouble.

ie, in C++ you still have to "dim" the variables... instead of "Dim i As Integer" it's "int i;" - you still have to declare the variables (and so forth), but it's how you go about doing that that's different.

Although, I will warn you - C++ is more stricter about things, so it would be a good idea to make sure you get in the habit of not cutting corners (for example, I'm pretty sure C++ is case sensitive with variables and such, so make sure to get in the habit of keeping case the same in basic, etc)

[Sam-U-Rai]

Oh cool cool. Yeah i'm more stricter with VB and I organize my stuff pretty good. We're gonna do an If/Then Project tomorrow because we finished all the notes for the chapter today. It doesn't look like that bad of a concept.

I think of it more as an Error Checker.

But that's cool. Thanks. I kinda got worried that it would be like way harder lawl.

[Sam-U-Rai]

Oh and I always wondered, how is the pay for like Software Engineering aka Programmer? I mean, I like computers and always wondered if it would turn into a career. Thing is though that will I have to sit in a small @$$ cubicle for the rest of my life?

That's what's turning me off about the whole thing.

[FLG]

For me going into C++ in college with no programming under my belt, i found it quite hard. Now the things i though were hard are easy and the current things were learing (functions at the molment) seem hard. HS is a much slower pace then college so im sure you will get the hang of it as you have time to. I started college right after labor day and midterms are already comming up in a week.

Blue is correct, all variables are case sensitive. Its good to use the copy paste method so you cant get things wrong.

[blue60007]

Yeah, C++ will be tougher (sometimes it's "strictness" can be frustrating), but like I said, knowing the concepts is key...

Here's a site that should give you an idea... (plug in job title and location...)
http://www.salary.com/

[rspassey]

I've never toyed around with C++ before, but I'd like to voice my opinion thus far: Learning another programming language is mostly just adapting to new syntax. However, only being able to write a few if / then statements in BASIC isn't over comlex... once you get into arrays and what not - it's not such an easy concept to understand no matter what language you are using... and that's still just scratching the programming surface.

there are a few things I do before I write each program:
1. Determine what the objective is
2. Make a flow chart
3. write psuedocode
4. draw pieces of code that are needed from my vastly growing library of other exercises (as to not having to write out lengthy code again)
5. comment as I go
6. finish code and then go back and read it over before compiling to make sure my logic makes sense.

If you follow similar steps, and keep to proper code conventions... you shouldn't have a problem picking up another language.


PS - I went from BASIC to Java.

[Statica]

Highly recommended that you stay away from BASIC as a first programming language. Teaches you really bad techniques.

[rspassey]

Sometimes, like it was in my case, BASIC is the only option if you want to take programming during HS. My Java course is a first year college course, that I'm taking my junior year... next year, there is a continuation of it... but in 10th grade, my only option was BASIC.

[alfie2]

here, Toronto Canada, my daugther is learning PASCAL in grade 10 computer class. IMHO, PASCAL is much more easier to learn and more compatible with C/C++ in term of syntax.

[faulkner132]

Originally Posted by Statica Highly recommended that you stay away from BASIC as a first programming language. Teaches you really bad techniques.

I disagree to a certain extent. Yes BASIC facilitates "spaghetti programming", but ultimately it is your teacher / teaching material which teaches poor technique.

QBASIC is what I learned with and it works well (for its intent) once you figure out how to use it as a functional language (a-la PHP4). I took high school "programming" and turned out to be like high school math - if you don't do it the *only* way the teacher knows how you get penalized for it. Personally, I think you are better off learning from a book but keep in mind my opinion is tainted due to my experience with poor teachers in high school.

College is a completely different ballgame. I can't speak how it is done everywhere, but they did not teach us programming languages, rather theory and techiques. Our assignments were literally along the lines of "write a program which takes this input and does this using X language". That is all we were given and had to learn the languages on our own (classes were taught using psuedo-code). At the time, I thought this was completely unfair because it doesn't prepare you for the job market, but one thing I now realize is once you truly understand the techniques, you pick up new languages very very quickly because all you have to learn is the syntax. This is what truly prepares you for the real world because, like any other industry, programming languages come and go like fashion fads. When teachers teach you how to do things in only a certain language, it essentially pigeon-holes you into that thinking where it is difficult to step outside the box because that is the only way you were taught. I've seen probably a dozen cases supporting both of my scenarios.

The moral of my story is to pay more attention to the theory behind what you are doing, because long term it will pay off (i.e. learn the skill, not the method)... I only wish I realized this while I was in school instead of the light bulb coming on 3 years later .

Getting back to the point of this thread, if I had to choose now, I would definitely go with Java as first language. It is object oriented and extremely well documented. Addtionally, its syntax is about as "transferrable" as it gets and it is a relatively easy language to learn.

I think Ryan is right on with this statement:

Originally Posted by rspassey there are a few things I do before I write each program: 1. Determine what the objective is 2. Make a flow chart 3. write psuedocode 4. draw pieces of code that are needed from my vastly growing library of other exercises (as to not having to write out lengthy code again) 5. comment as I go 6. finish code and then go back and read it over before compiling to make sure my logic makes sense. If you follow similar steps, and keep to proper code conventions... you shouldn't have a problem picking up another language.

[doctorgonzo]

Originally Posted by rspassey there are a few things I do before I write each program: 1. Determine what the objective is 2. Make a flow chart 3. write psuedocode 4. draw pieces of code that are needed from my vastly growing library of other exercises (as to not having to write out lengthy code again) 5. comment as I go 6. finish code and then go back and read it over before compiling to make sure my logic makes sense.

I don't know if all of those steps are necessarily good ones. #1 is great, obviously. #4, code reuse, again a good idea. #5, commenting, is something that happens too little (and I am one of those who does not comment my code enough, I admit).

But I never make flow charts or do p-code for the most part. Programming today is object-oriented, and OO techniques are different from the linear techniques of FORTRAN, BASIC, and those languages of old.

True, there are times when you are going to be doing some very linear programming, and these ideas may help. But there are also times when your programs are going to be modelling real life in such a way that you need to think along OO lines. For example, when I was creating a tracking database, it was far better to think along the lines of "What data does a customer have, and what can I do with a customer? What about an order?" In OO programming, you are going to be creating "objects" and then manipulating them, sometimes asynchronously. It's different from programming in BASIC.

I started out in BASIC too long, long ago. But it taught me very little about how to make good programs.

[faulkner132]

Originally Posted by doctorgonzo But I never make flow charts or do p-code for the most part.

Personally, I have found doing this very helpful. In my experience, the design is infinitely better when you don't do a "rough draft" in code.

Creating an ER Diagram/Flow Chart/Code Skeleton/whatever you want to call it makes you think about what you are going to do before you start coding instead of realizing, "I should have done it this way" in the middle of coding.

[rspassey]

Originally Posted by doctorgonzo I don't know if all of those steps are necessarily good ones. #1 is great, obviously. #4, code reuse, again a good idea. #5, commenting, is something that happens too little (and I am one of those who does not comment my code enough, I admit). But I never make flow charts or do p-code for the most part

I guess it's argueable that flowcharts and p-code are not entirely necessary steps; but with programing, I feel like the end does NOT justify the means - on today's computers, they are so powerful, doing a program that *longest* and most *complex* way probably will compute just as quickly - however it's still not the most efficient code.

Flowcharts and psuedocode allow me to determine which way is the *best* way to tackle the problem determining on my current skill set.

For example... the other week we had an assignment to take take a user input integer and then spit out the individual digits and their sum. in JAVA, this could be done quite quickly by using the string length and substring code... probably in under 20 lines of code.... however I, having a relatively exhausting and lazy day, decided to tackle it the mathematical way (using modulus division and what not) and it got really complex, really quickly... nonetheless, my way worked just as well and actually was capable of them adpating to many other instances... but it was also 3 of 4 times longer than it needed to be. I incorrectly judged which way was best to tackle this problem by automatically excluding the possibility of using strings becuase of the manipulation of integers.

[Force Flow]

Depending on the problem, you can do different things.

Sometimes I draw flow diagrams, other times I draw class attribute diagrams. Sometimes both. Sometimes neither.

It all depends on what *you* need to have a good grasp of the problem, and what you need to do to get it completed with a minimum of errors. The quality of your code always counts, and if you have poor coding habits, chances are, you'll end up with a shoddy program.

Personally, I wouldn't touch C++ because of it's messy way of handling things and messy syntax. If you like the way it's handled, that's fine. Just make sure you engage in good coding practices supported by half way decent planning.

[faulkner132]

Originally Posted by Force Flow It all depends on what *you* need to have a good grasp of the problem, and what you need to do to get it completed with a minimum of errors. The quality of your code always counts, and if you have poor coding habits, chances are, you'll end up with a shoddy program.

Right on, to each their own. Never underestimate the importance of code readability... if you do it will end up costing you more time in the long run.

Originally Posted by Force Flow Personally, I wouldn't touch C++ because of it's messy way of handling things and messy syntax. If you like the way it's handled, that's fine. Just make sure you engage in good coding practices supported by half way decent planning.

Ditto, I'll leave memory allocations up to the OS... that's what it is supposed to do anyway.