I have been trying to learn a language and haven't actually made a working program yet. I don't know what I am really doing? Is it just practice and then eventually learn?

I'm not asking which ones to learn but how to begin learning a programming language. Practice and repetitiveness before being able to make a program on your own?

My goal is to make my own programs but how do I begin learning a language and then have that end goal?

How do I go from point A to point B? You can use any language as an example. Just want brief simple answers and direct. No need to reference where a language is, but rather a method of learning the language.

Thanks,
Guy Skarpz

First find a good text book for that language, either ask related experts or search on Google.
Second start learning it and try to solve each exercise at the end of the chapter. don't leave any question.
Third try to solve by your own, later ask other to help
Fourth revise your concepts after a week this will help you to know how much you have learn

Now try to make program for your own problems or little work.

How to you think you would begin to learn how to use your freshly
purchased "Chainsaw"?

What would be your first step?
Slicing "salad tomatoes" and cutting "finger nails" with a "Chainsaw"?
Would you start with that?

I guess you would do that, if and only if, you don't know why the
hell did you purchase the Chainsaw OR what is a Chainsaw!

Once you know its "purpose" you won't be saying the following:
The point here is that "languages" are just the "tools" which are meant
to serve a particular purpose.
Different languages have different purposes.

Until and unless you are crystal clear about the purpose of the tool,
you'll always feel lost. The reason is that you'll be trying to solve
the problems which don't exist!

* Figure out "why" did you select "that" language?
* Which softwares would you like to build?
* Is that language considered best for the software in which you are
interested?

Once you figure out the answers to all these questions you can start your
own "dummy project".
1. On paper, plan what features would you like to have in your dummy
software.
2. Pick the smallest feature and figure out how to use that language to
build that feature.

This way, IMO, you'll be always knowing what and why you are doing.
You'll have a purpose, and that purpose will keep you motivated.
You won't feel lost.

Practice is the "secondary" thing.
First issue is to find the "problem". Once you have found the problem
then of course you need to practice hard to find a solution to that
problem.

I haven't heard of anyone using Assembly language to build a website.

1 members found this post helpful.

Anisha,

That's the answer I've been looking for. That helps a lot even though it is a simple answer and makes me feel like I made a dumb question, but this will help me start from scratch easier. Thank you.

I want to develop games. I want to start with a simple game first and then learn bigger games.

First, desktop gaming with simple programming and then eventually the bigger stuff like a Second Life viewer.

My end goal is a Second Life Viewer.

I need to learn how to make it for Linux or Windows or mac or Android or iOS.

I have Linux and will start with a 32 bit system since I know for sure that Second Life works best with a 32 bit system.

So, that's my plan and I want to start somewhere but I need to look into it more.

1 members found this post helpful.

It is nice to know that you already have a goal.

My advise would be to spend some days in finding out a language:
1. Which has a full support for graphics.
2. Which is platform independent.
3. Which has a good documentation.

Next step should be to design a smallest game.
No, not in your mind, on the paper. Use UML.
List out all the features of the game.
Break those features into tiniest tasks - till you get to the point
where you can't break them any further.

Then, when you start with the language, you'll always have something
to try about w.r.t the tiny features of your game.

Starting with the "tiniest" game is actually necessary.
That way you'll visualize the things getting done.

1 members found this post helpful.

Thanks, that helps a lot. I just got confused in programming but focusing in the tiniest game or simplest and work my way up sounds like a good idea. Now I can get started soon.

1 members found this post helpful.

What I recommend is you set a reasonable goal and try to accomplish it. So, try to write a simple program using reference materials depending on the language. I have never been able to just jump in and write a large and complicated program without knowing how to program smaller and simpler ones.

Some planning ahead is required, so do have some paper around to make notes on. I rarely stick to the original plan, and the plan just evolves with time. I'm not one of those people that can plan every detail exactly and then accomplish this exactly. I just make a rough draft of what I want to do and implement the details when I get to them.

1 members found this post helpful.

That's backwards. Experienced programmers decide what program they want to write and then pick a language (or combination of languages) that would be suitable.

If you do have a language in mind, we can recommend specific resources to get you started with that language.

1 members found this post helpful.

That is the best advice given so far.
If you start out trying to create a solution and go looking for a problem for it to solve, you'll never get anywhere. If you've been using computers for very long, you surely must have encountered situations that you thought could have benefited from a (missing) tool to help you. Use one of those as an objective, and start decomposing the problem into smaller parts that you can solve. Don't make your objective too big or difficult; smaller is much better. Writing some GUI application as your first program is totally impractical. There are way too many concepts to learn before you can understand how to write interactive applications.
Someone said to get a book on the language you choose, and this is partly right. I find that there are usually at least three classes of books that you will want. First, you want a beginner's tutorial. Many of these will introduce basic programming fundamentals that are common to most or all of the popular programming languages in use today. These concepts are very important, and you need to learn them early on. The tutorial book will cover all sorts of such things, and should also explain some of the practical aspects of the programming tools and components that you will use to program in the language you've chosen; how to install or find the compiler, commandline basics, etc. After a short while, you'll find a need for a reference book. This won't teach you how to program; it will just provide the necessary facts and rules that are needed to write programs that will build and work. It will be concise and organized in a way that facilitates lookup of facts as they are needed. It will be useful for as long as you are using the language. A couple of other kinds of books will be advanced tutorials, that assume you have an understanding of the basic concepts, and try to expose you to difficult or special purpose aspects of the language. You'll know when you're ready for one of those. Finally, there are cook-book style books, that provide lots of examples of how to solve common problems, and provide working examples of code that performs some relatively complete task. Usually, these are targeted at a kind of intermediate knowledge level. They can provide useful starting-point code samples, upon which you can develop your own applications, or simply incorporate working code into work you've already started.
I will close off by adding that you should not expect to be productive in programming for at least several months, possibly years, even if you are able to invest a considerable and extended effort in the learning process. Since you have asked the question about how to start, I conclude that you are not one who naturally and independently seeks out answers. All of the best programmers that I know are tenacious about learning their craft, and do so with very little guidance explicitly sought from others. It is not a pejorative that you may not have this makeup, and I bring it up only to point out that your learning curve may be very long, and to warn you not to be discouraged if you haven't written some substantial body of work after a short time.

--- rod.

1 members found this post helpful.

only dumb question is the one not asked

best advice I can give is look up open source game engines, learn how to work with one of those as well as some simple programming for the language in which the game engine is written, once you understand the basics of how to work with an existing game engine, then start figuring out how to write your own game engine.
as for when you start with your own games from scratch, start with text based games and then move into learning a graphics library's api.


good luck

start with Linux first, then once you get it built and stable, then learn how to port it.

second life is an online game, so it doesn't really matter whether you write in 32 or 64bit as long as the game talks to the server properly, the server doesn't care what architecture the client runs.

again, have fun and good luck.

1 members found this post helpful.

You are right, but I would not choose a specific language (that I may not even know) just because it would be slightly easier to program in it, or that it would be more suitable. I'm sure you can do anything you can possibly imagine in C/C++, right ? It is true however, that it take much less time and effort to write a shell script that might accomplish the same goal. There is a right language for everything, but that doesn't mean that you have to use that language and not something a bit more challenging to accomplish the same goal. Sometimes you must choose the harder path, and you will learn more and accomplish more than with easier paths.

I say choose a base language, learn the basics of what programming consists of, and then you can learn other languages and become an expert. Maybe you don't even want to become an expert, maybe you just want to accomplish a goal and maybe that goal is just to learn how to program. If you learn the basic structures that nearly all programming languages use, it will be much easier to learn other languages and then choose the right language.

1 members found this post helpful.

Something you need to learn that is far more important than the programming language is how to think like a programmer. That came naturally to me, which has handicapped me when trying to teach it (it is easier to teach something if you overcame the difficulty of learning it, vs. you either learned it easily or never really learned it).

The one of my sons who is most interested in programming (games of course) doesn't think like a programmer. I can certainly recognize the specific results of that failure even if I don't know how to teach him to avoid it. It is a failure that is far more common than success among beginners who set out to learn to program games:

My son's growing game program is filled with giant redundant data structures. It has chunks of code scattered all over doing the same basic operations in slightly different ways multiplied by doing it on slightly different objects. Functionally it is still a very crude game, but the quantity of code and the amount of time invested would be consistent with a much more sophisticated game.

As an inexperienced programmer, it is natural that you won't see the ways to exploit the similarity between sections of code. It is always easier to write two similar sections of code than to write one section of code that does the job of both (it is especially easier to write two once you know how to use copy/paste in the editor to duplicate the identical parts). But each time you fail to merge similar sections of code, you make it harder to merge future similar sections and you soon are multiplying the quantity of code by far more than the mere factor of two that seems to be in play each time the issue comes up.

It is important to build up from simple problems (simple games) toward more complicated ones. But while doing so, you should find some way to avoid reenforcing bad habits.

When I was in high school (VERY LONG AGO), I tutored a group of graduate students in BASIC programming. I agreed for the next semester to tutor the same group in FORTRAN, even though at that time I knew nothing about FORTRAN. I had learned BASIC in one day by reading the manual and immediately inferring all of the best programming practices that followed from the rules of the language. I assumed I would do the same with FORTRAN, and probably would have, but I procrastinated before buying that manual and when I needed it to prepare for the first tutoring session, the university book store was out of stock. So as my clients asked me how to do their first assignment in Fortran, I knew nothing about Fortran beyond the common claim that it was similar to BASIC. So I asked them "How would you do this same assignment in BASIC?" and was surprised that after getting A's in a semester of BASIC programming, they still had trouble with that question. After I asked a few leading questions, that came back to them, and since (unlike me) they had read the Fortran manual and Fortran really is similar to Basic, as they realized that they knew how to do that assignment in Basic, they also realized they knew how to do it in Fortran and they told me how to do it (thinking I was checking their answers rather than just learning some Fortran from their answers). I never did buy a Fortran manual. I realized that for a semester I had taught them Basic, when I should have been teaching them programming. In the second semester, I taught them programming. I did that all second semester by asking questions, rather than by giving any answers, partially because I was keeping secret the fact that I only knew the Fortran they had taught me up to that point and I usually couldn't give answers, but also because I could see it worked. The point of this story is the importance of learning to program rather than learning a programming language.

I wish I knew how to tell you (or more importantly my son) how to learn to program. Over many years, I have tutored some students who get that nearly as instantly as I had myself and just need to have a few more advanced methods demonstrated that they can recognize the value of, but just wouldn't think of themselves. I have tutored students like the ones in my story above, who need to be constantly guided toward learning to program as distinct from learning a programming language. Unfortunately, most often I have failed with students who just don't get the concept no matter how I have tried to present it (really unfortunately including some programmers I work with and including my son).

For you, I wrote all this in the hopes that being aware there is something important in "thinking like a programmer" may help you find the way to learn it.

5 members found this post helpful.

johnsfine has given a good set of answers, and I want to put them in a shorter and metaphorical terms: if you want to become a professional dancer or figure skater, you do not first learn dancing or figure skating, you first learn choreography and are trained to be physically fit.

That may look/feel boring and not at all flashy, but that's the way.

1 members found this post helpful.

I want to be clear on this. Some people didn't understand and some people did understand. In programming the end goal is to write my own programs. That is the ultimate end goal but even further that I would have to create my own language after that. But that is the ultimate end goal. The Finish Line. People were confusing the finish line with the start. I have a friend who taught me how to think like a professional programmer but I forgot how to begin. Now I know that it is likea company where you start small and end up big. But I want to see which language I need to use for what I want. Iknow know I want to go towards OpenSim instead of SecondLife. Too much complications with something that isn't open source and I get to grow faster with an open source like OpenSim. I can't do much right now since my hard drive doesn't work and I'm using Knoppix which makes me not see what I type sometimes but it works. ANyways, thanks for the help. I need to just do it and start with a small program and grow gradually bigger and possible use those Learn whatever the hard way programming guides. The proper language is the one for the program I wish to create that is the Viewer for OpenSim. I shall see what happens soon, but I just found work and when I get my laptop back soon I can start on it again or just type up code until the time being even though I'm not sureif I can test it. I don't recommend copy and paste. Once you type over and over then you learn it faster and faster and you type faster and you learn the code. Copy and paste limits you and slows you down.

Thanks everyone. If you have more just say the word.

If it helps ... the first program that I ever wrote was 8 lines long, took me 6 months to write (in 1977...), and had a bug in it.

I have written more than 999,992 lines of source-code since then, and I'm still at it. (Still luvin' it, too. Crazy me.)

My best advice: persevere. If you feel like you're taking "a sip from a fire-hose," you're doing something right.

The most difficult thing about computer programming is, indeed, "how to think like a programmer." A computer programming tool ... be it an ALGOL-derivative language like the ones we use, or an Excel spreadsheet, merely provides the ability to translate a set of instructions into something that the hardware can carry out exactly. The true difficulty is not "figuring out where the parentheses and semicolons go," but determining what you want the hardware to (blindly...) do.

If you ever get a chance to watch the original movie, Tron, I suggest that you pay particular attention to the "light-cycle race." The cycles would blast through the track given by The Programmer's instructions, following those instructions exactly. ("The Programmer" was basically a god...) If there was the slightest error, the light-cycles would crash. (They would always perfectly execute whatever the instructions told them to do, but if those instructions were not perfect, the light cycle would crash.)

1 members found this post helpful.