Help me learn how to program before I tear my hair out.
July 19, 2006 6:55 PM Subscribe
I've been trying to learn how to program, but it's not going well.
I really want to learn how to computer program (my troubles certainly aren't for a lack of ambition, I can tell you). I've tried quite a few different books on the more popular languages (C++, Python, C#, Visual Basic), but none of them really get through to me. I always feel like I'm just parotting the examples and not really learning anything. I've been having more trouble not with coding, but with training my brain to think in terms of algorithms. Are there any resources (books, web sites, etc) or exercises I can use to try to get me to start thinking like a programmer?
I really want to learn how to computer program (my troubles certainly aren't for a lack of ambition, I can tell you). I've tried quite a few different books on the more popular languages (C++, Python, C#, Visual Basic), but none of them really get through to me. I always feel like I'm just parotting the examples and not really learning anything. I've been having more trouble not with coding, but with training my brain to think in terms of algorithms. Are there any resources (books, web sites, etc) or exercises I can use to try to get me to start thinking like a programmer?
Well, you won't be able to think like a programmer until you've done a little coding. Why not motivate yourself and tackle some tiny projects that pique your interest? Also it sounds like you need to make choices about what audience you're programming for... for example Visual Basic is not very helpful for web programming, and PHP isn't all that great for a standalone Windows application.
posted by zek at 7:02 PM on July 19, 2006
posted by zek at 7:02 PM on July 19, 2006
Also maybe this will give you some motivation... when I learned PHP I just cobbled together a tiny little quiz that allowed web visitors to assess their "redneck quotient"... some website picked it up and I got swamped with E-mails. I eventually had to take it offline as I didn't have time to adjust and tweak it, but it was rewarding for such a tiny bit of learning work.
posted by zek at 7:05 PM on July 19, 2006
posted by zek at 7:05 PM on July 19, 2006
SirStan is right. You need little projects to do to actually learn the new language. The trick is: don't pick a huge application, just do something simple.
For instance:
1. Learn how to flip a string around ("goodnight" to "thgindoog").
2. Figure out how to read from a file and write to another file.
3. Build a widget that performs useful date functions.
4. Build a tiny app that grabs a web page, parses something useful and then passes along the result.
posted by bshort at 7:07 PM on July 19, 2006
For instance:
1. Learn how to flip a string around ("goodnight" to "thgindoog").
2. Figure out how to read from a file and write to another file.
3. Build a widget that performs useful date functions.
4. Build a tiny app that grabs a web page, parses something useful and then passes along the result.
posted by bshort at 7:07 PM on July 19, 2006
The best way to learn to program is to actually write a program.
Find a practical problem, and code your own solution.
Mathematical problems with lengthy algorithmic solutions are good candidates for a beginning programmer.
For example, you could start with a simple program that would list the prime factors of any given number, and perhaps progress to a program that could count/list prime numbers <= a given number.
posted by The Confessor at 7:11 PM on July 19, 2006
Find a practical problem, and code your own solution.
Mathematical problems with lengthy algorithmic solutions are good candidates for a beginning programmer.
For example, you could start with a simple program that would list the prime factors of any given number, and perhaps progress to a program that could count/list prime numbers <= a given number.
posted by The Confessor at 7:11 PM on July 19, 2006
I second zek's sentiments. I'm a coder and didn't start "thinking like one" until I'd already been programming for awhile. And my first serious project was a simple one that allowed me plenty of time to learn as I went, reading help files and searching online for solutions. Google Groups helps me out a lot these days and there are countless other forums for coding help (especially easier "newbie" questions).
Also, I'd highly recommend Karl Moore's books as they're helpful as well as humorous and really helped me to pick up the basics.
Best of luck to you.
posted by mezzanayne at 7:13 PM on July 19, 2006
Also, I'd highly recommend Karl Moore's books as they're helpful as well as humorous and really helped me to pick up the basics.
Best of luck to you.
posted by mezzanayne at 7:13 PM on July 19, 2006
You might want to think about trying out algorithms. Once you learn the syntax of a language, go to topcoder & look at some of their lowest level algorithm challenges. One of those will keep you busy for a long, long time.
But basically, decide why you want to learn to program. Focus on those kinds of applications.
My emails in my profile. I use C++ & C# every day, perl less so. Feel free to ask questions.
posted by devilsbrigade at 7:14 PM on July 19, 2006
But basically, decide why you want to learn to program. Focus on those kinds of applications.
My emails in my profile. I use C++ & C# every day, perl less so. Feel free to ask questions.
posted by devilsbrigade at 7:14 PM on July 19, 2006
Alternatively, you could design a webpage...
XHTML/CSS aren't that difficult to learn, and once you've got them down... well, php has a very nice, natural learning curve. You can start with simple "copyright YYYY" includes, and eventually progress (as I did) into mySQL queries, dynamic content via url manipulation, and full-site templates.
#php and #html IRC channels on Dalnet (which i frequent) or Freenode (probably more populated) are good sources for personalized help, so long as you're not looking for a nanny.
posted by The Confessor at 7:26 PM on July 19, 2006
XHTML/CSS aren't that difficult to learn, and once you've got them down... well, php has a very nice, natural learning curve. You can start with simple "copyright YYYY" includes, and eventually progress (as I did) into mySQL queries, dynamic content via url manipulation, and full-site templates.
#php and #html IRC channels on Dalnet (which i frequent) or Freenode (probably more populated) are good sources for personalized help, so long as you're not looking for a nanny.
posted by The Confessor at 7:26 PM on July 19, 2006
Find something that's of real use to you. Have the software do your homework if you're still in grade school. Find some problem that's of intellectual interest to you or that you think would be entertaining. Unless it's personal and useful, I doubt you'll be motivated enough to stick with it.
As far languages go, if I were teaching someone programming, I'd start them out on Processing. It's really Java in a pretty dress, but man, it's REALLY easy to get started writing stuff with graphics, and seeing that immediate feedback is way more fun than knowing that you've fiddled some bits in memory and output "hello world". Check out the demos and tutorials; it's really impressive how simple it is to get going and work incrementally on your previous successes.
posted by jewzilla at 7:27 PM on July 19, 2006
As far languages go, if I were teaching someone programming, I'd start them out on Processing. It's really Java in a pretty dress, but man, it's REALLY easy to get started writing stuff with graphics, and seeing that immediate feedback is way more fun than knowing that you've fiddled some bits in memory and output "hello world". Check out the demos and tutorials; it's really impressive how simple it is to get going and work incrementally on your previous successes.
posted by jewzilla at 7:27 PM on July 19, 2006
You might want to look at Head First Java, a conversational book that might be a better format for you. Like the other 'Head First' books, it walks the line between just giving you the information and making you figure it out yourself. It basically takes you on a problem-solving journey, letting you get just frustrated enough to think hard about something before they tell you how it's really done. It's not for everybody (and not always for me) but it may be for you.
You might also like Objects First With Java, which uses a sort of visual IDE to help you conceptualize the relationships between the objects in your project. One thing I admired about this book: they explain the concepts clearly, and then they give you exercises that are about ten times more difficult than the examples you just read (while still being quite achievable given what you've learned). And they do point out repeatedly that it's a book about programming that just happens to use Java. (Caveat: I linked to the third edition, but read the second edition. Another caveat: Some of the exercises don't have answers in the book, at least in the 2nd edition. You have to get the teacher's edition for all the answers, and to do that you have to buy through a school. Still, 90% of the time you'll know whether your answer is right or not just by whether your program works properly).
Then, of course, there is Design Patterns and the arguably more accessible Head First Design Patterns, not really about algorithms per se but certainly about thinking like a programmer. Finally, there's Data Structures and Algorithms In Java, which is dated (came out before there were Collections to speak of), but that is part of its charm, as it walks you through how to do various things that it's helpful to understand even though you don't technically have to do them on your own anymore (e.g. construct a linked list using regular arrays).
Obviously, I am biased towards Java, and you didn't mention Java, but what can I say, that's what I know (a little bit) about. I also have done some programming in Visual Basic For Applications (Excel), and can recommend some good books in that regard if you're interested.
posted by bingo at 7:32 PM on July 19, 2006
You might also like Objects First With Java, which uses a sort of visual IDE to help you conceptualize the relationships between the objects in your project. One thing I admired about this book: they explain the concepts clearly, and then they give you exercises that are about ten times more difficult than the examples you just read (while still being quite achievable given what you've learned). And they do point out repeatedly that it's a book about programming that just happens to use Java. (Caveat: I linked to the third edition, but read the second edition. Another caveat: Some of the exercises don't have answers in the book, at least in the 2nd edition. You have to get the teacher's edition for all the answers, and to do that you have to buy through a school. Still, 90% of the time you'll know whether your answer is right or not just by whether your program works properly).
Then, of course, there is Design Patterns and the arguably more accessible Head First Design Patterns, not really about algorithms per se but certainly about thinking like a programmer. Finally, there's Data Structures and Algorithms In Java, which is dated (came out before there were Collections to speak of), but that is part of its charm, as it walks you through how to do various things that it's helpful to understand even though you don't technically have to do them on your own anymore (e.g. construct a linked list using regular arrays).
Obviously, I am biased towards Java, and you didn't mention Java, but what can I say, that's what I know (a little bit) about. I also have done some programming in Visual Basic For Applications (Excel), and can recommend some good books in that regard if you're interested.
posted by bingo at 7:32 PM on July 19, 2006
Java is a great language if you have a need for cross platform development, but it is extremely hard to learn beacuse of strong typing.
Stick with a scripted language that isn't strongly typed.
posted by SirStan at 7:36 PM on July 19, 2006
Stick with a scripted language that isn't strongly typed.
posted by SirStan at 7:36 PM on July 19, 2006
I liked "Java in a Nutshell." There's also something to be said for the old Dale/Weems joint "Pascal: Data Structures," the book that taught me how to program, but no one uses Pascal anymore so it might be a huge detour for you.
Both of these books are very data-structure oriented, which is one way to approach modern programming.
posted by ikkyu2 at 7:44 PM on July 19, 2006
Both of these books are very data-structure oriented, which is one way to approach modern programming.
posted by ikkyu2 at 7:44 PM on July 19, 2006
I usually get beaten for suggesting this, but I really do feel Flash, and it's programming language, Actionscript, are a really good way to get into programming for people who have started late or need a more visual and immediate way of seeing their efforts displayed.
Actionscript is similiar to C in many ways, different in many, too. When you've learnt 'if/then/else', 'for', 'do/while', etc, you'll be far more confident in what you're doing, and you'll find it far easier to transfer what you've learnt to other languages. For example, Actionscripts implementations of the above are identical to C/C++'s.
The biggest stumbling block I've seen for beginning programmers is understanding variable types - a language like Actionscript hides all of that for you. When you've made some simple programs in Flash, move on to the 'harder' stuff. Or become a shit hot Actionscript programmer and earn a mint because of the lack of really skilled talent in that area ;)
posted by toby\flat2 at 7:55 PM on July 19, 2006
Actionscript is similiar to C in many ways, different in many, too. When you've learnt 'if/then/else', 'for', 'do/while', etc, you'll be far more confident in what you're doing, and you'll find it far easier to transfer what you've learnt to other languages. For example, Actionscripts implementations of the above are identical to C/C++'s.
The biggest stumbling block I've seen for beginning programmers is understanding variable types - a language like Actionscript hides all of that for you. When you've made some simple programs in Flash, move on to the 'harder' stuff. Or become a shit hot Actionscript programmer and earn a mint because of the lack of really skilled talent in that area ;)
posted by toby\flat2 at 7:55 PM on July 19, 2006
I feel for you. I started learning to program in 1979, on a Commodore PET with BASIC in ROM on display on a shop counter. It didn't do anything useful until you HAD programmed it, so the motivation to learn was there, and the programming environment was simple enough to be understandable.
These days, it's all Document Object Models and use cases and design patterns and IDE's and endless amounts of SUPERFLOUS CRAP that's supposed to make everybody's code all clean and reusable and nice, and the net effect is to make EVERY bloody thing so insanely complicated and interwoven that NONE of it makes any sense to people just starting out, and MOST of it continues to make no sense to people who've been working in other little corners of it for years.
C++???? For fuck's sake. Nobody can learn to program in that randomly thrown together abortion of a language. You can't just look at a piece of C++ code and know what it does; depending on what everything else around it does, it could be doing damn near anything. It's hard enough figuring out when it runs, let alone what it does when it does run.
You won't grok C++ until you know C.
C is actually straightforward enough for a beginner to learn, and once you've learned to think in C, you can learn to think in anything else fairly quickly. It doesn't hide much from you, so you're pretty much forced to get to grips with what the machine's doing under the hood. Lots of people will tell you this is Bad, and that you need to be getting away from Worrying About Side Issues like Performance or Exact Implementation Details, and that you need to Make It Correct before you even think about Making It Fast. Fuck those people. They mean well, but they've forgotten what it's like to be a beginner.
Set yourself up with a Linux box; get an old computer and put Ubuntu on it.
Figure out how to enter, compile and run hello-world.c.
Then grab the following books:
Harbison and Steele
Wirth
Kernighan and Pike
That should get you on your way.
posted by flabdablet at 7:58 PM on July 19, 2006 [4 favorites]
These days, it's all Document Object Models and use cases and design patterns and IDE's and endless amounts of SUPERFLOUS CRAP that's supposed to make everybody's code all clean and reusable and nice, and the net effect is to make EVERY bloody thing so insanely complicated and interwoven that NONE of it makes any sense to people just starting out, and MOST of it continues to make no sense to people who've been working in other little corners of it for years.
C++???? For fuck's sake. Nobody can learn to program in that randomly thrown together abortion of a language. You can't just look at a piece of C++ code and know what it does; depending on what everything else around it does, it could be doing damn near anything. It's hard enough figuring out when it runs, let alone what it does when it does run.
You won't grok C++ until you know C.
C is actually straightforward enough for a beginner to learn, and once you've learned to think in C, you can learn to think in anything else fairly quickly. It doesn't hide much from you, so you're pretty much forced to get to grips with what the machine's doing under the hood. Lots of people will tell you this is Bad, and that you need to be getting away from Worrying About Side Issues like Performance or Exact Implementation Details, and that you need to Make It Correct before you even think about Making It Fast. Fuck those people. They mean well, but they've forgotten what it's like to be a beginner.
Set yourself up with a Linux box; get an old computer and put Ubuntu on it.
Figure out how to enter, compile and run hello-world.c.
Then grab the following books:
Harbison and Steele
Wirth
Kernighan and Pike
That should get you on your way.
posted by flabdablet at 7:58 PM on July 19, 2006 [4 favorites]
If your problem is not coding, but "thinking like a programmer", perhaps what you want is a textbook from a class instead of a book on how to get things done. The book from MIT's intro class is online. It's pretty abstract, and explicitly focuses on how to think, rather than on the mechanics of the code.
posted by aneel at 8:02 PM on July 19, 2006 [1 favorite]
posted by aneel at 8:02 PM on July 19, 2006 [1 favorite]
Pah. MIT these days is chockablock with high priests. Track Kaufman down as well.
posted by flabdablet at 8:11 PM on July 19, 2006
posted by flabdablet at 8:11 PM on July 19, 2006
I can kinda recommend How To Think Like a Computer Scientist. A friend gave it to me, and I haven't read it much while I'm learning Python, but she raved about it. He's faculty at my school, and is a great teacher. It's supposed to be really good for taking people from knowing nothing to ... thinking like computer scientists.
Also: I'd recommend Python as a first language over any of the other's you're trying. There's plenty I don't like about it, but it's good enough for picking up the general programming skills.
posted by heresiarch at 8:12 PM on July 19, 2006
Also: I'd recommend Python as a first language over any of the other's you're trying. There's plenty I don't like about it, but it's good enough for picking up the general programming skills.
posted by heresiarch at 8:12 PM on July 19, 2006
I recommend the How to Design Programs book (fully available on line for free), which really focuses on, well, how to think algorithmically. It uses a somewhat obscure language called Scheme rather than Java or something like that, which puts some people off, but the principles apply to coding in all languages and using a simple language like Scheme lets them REALLY avoid the "just parrot an example" trap so many books fall into. I don't think there's a single instance where they ask you to write anything without understanding what it does.
More importantly, they focus on the deeper issues of why you'd write that line of code in the service of solving your problem; that skill is very valuable and completely independent of the particular language you end up working with down the line. Don't make the mistake of thinking that learning programming languages is like learning human languages, where learning one is only marginally useful in learning another; in programming, once you really understand the principles of programming in a couple of paradigms, you can pick up any language you want or need to in no time flat. Conversely if you don't understand the underpinnings, then you can know the syntax of a dozen different languages and still not be able to code your way out of a paper bag.
NB I work in the same research group as HtDP's authors.
posted by jacobm at 8:12 PM on July 19, 2006 [2 favorites]
More importantly, they focus on the deeper issues of why you'd write that line of code in the service of solving your problem; that skill is very valuable and completely independent of the particular language you end up working with down the line. Don't make the mistake of thinking that learning programming languages is like learning human languages, where learning one is only marginally useful in learning another; in programming, once you really understand the principles of programming in a couple of paradigms, you can pick up any language you want or need to in no time flat. Conversely if you don't understand the underpinnings, then you can know the syntax of a dozen different languages and still not be able to code your way out of a paper bag.
NB I work in the same research group as HtDP's authors.
posted by jacobm at 8:12 PM on July 19, 2006 [2 favorites]
The first programs I ever wrote were BASIC games copied line for line out of 3-2-1 Contact magazines. The very first time I left out anything in parenthesis because I thought they were comments (hey, this was before I even knew about negative integers). So simply copying and seeing results isn't such a bad way to start.
I probably didn't really begin to understand algorithms until my high school pascal class. Our book would give us challenges and then we'd have to solve them under some constraint. For example (and this is on a console), draw a 9x9 diamond with *'s using only two loops. Maybe I could have done it real easily with 3 loops, but now I had to sit and puzzle over how to eliminate one.
We did dozens of these. They helped me think critically about the problem. They encouraged me to actually design a solution instead of just pound out code until it works.
I don't really have a book recommendation for you because I don't tend to buy programming books anymore (once you've seen a couple languages, you've mostly seen them all). I'd suggest buying one that challenges you with logic puzzles, opposed to one that's orientated towards building your first app as soon as possible.
posted by sbutler at 8:13 PM on July 19, 2006
I probably didn't really begin to understand algorithms until my high school pascal class. Our book would give us challenges and then we'd have to solve them under some constraint. For example (and this is on a console), draw a 9x9 diamond with *'s using only two loops. Maybe I could have done it real easily with 3 loops, but now I had to sit and puzzle over how to eliminate one.
We did dozens of these. They helped me think critically about the problem. They encouraged me to actually design a solution instead of just pound out code until it works.
I don't really have a book recommendation for you because I don't tend to buy programming books anymore (once you've seen a couple languages, you've mostly seen them all). I'd suggest buying one that challenges you with logic puzzles, opposed to one that's orientated towards building your first app as soon as possible.
posted by sbutler at 8:13 PM on July 19, 2006
flabdablet: That's a great idea, teach them about memory management first! Everyone will understand that!
There's a subset of C++ that can be learned quite easily. The rest can be integrated later. I would much, much prefer to learn C++ first and C later than the other way around. It is quite possible to make fully functional applications in C++, especially smallish programs, without touching a pointer, reference, template, or even new/delete yourself. Just because C++ gives you a lot doesn't mean you have to use it, and a good book will show you how to get stuff done first, and then why it works.
You can't just look at a piece of C++ code and know what it does; depending on what everything else around it does, it could be doing damn near anything. It's hard enough figuring out when it runs, let alone what it does when it does run.
Lets compare (using namespace std is assumed):
C++:
bool myfunc(string a, string b)
{
if(a == b)
return true;
else
return false;
}
C:
bool myfunc(const char* a, const char* b)
{
if(!strcmp(a, b))
return true;
else
return false;
}
Now, not only is the C++ version more intuitive, but safer. What happens if you feed a non-null terminated string into the C version? Why should a learning programmer have to worry about terminating their strings? About allocating just enough for the string + the terminator? C is very useful to know, but its hardly what you should learn first.
posted by devilsbrigade at 8:14 PM on July 19, 2006
There's a subset of C++ that can be learned quite easily. The rest can be integrated later. I would much, much prefer to learn C++ first and C later than the other way around. It is quite possible to make fully functional applications in C++, especially smallish programs, without touching a pointer, reference, template, or even new/delete yourself. Just because C++ gives you a lot doesn't mean you have to use it, and a good book will show you how to get stuff done first, and then why it works.
You can't just look at a piece of C++ code and know what it does; depending on what everything else around it does, it could be doing damn near anything. It's hard enough figuring out when it runs, let alone what it does when it does run.
Lets compare (using namespace std is assumed):
C++:
bool myfunc(string a, string b)
{
if(a == b)
return true;
else
return false;
}
C:
bool myfunc(const char* a, const char* b)
{
if(!strcmp(a, b))
return true;
else
return false;
}
Now, not only is the C++ version more intuitive, but safer. What happens if you feed a non-null terminated string into the C version? Why should a learning programmer have to worry about terminating their strings? About allocating just enough for the string + the terminator? C is very useful to know, but its hardly what you should learn first.
posted by devilsbrigade at 8:14 PM on July 19, 2006
(Caveat: I learned the way that other people here are suggesting. Finding a project, learning just enough to make it work, thinking of another feature, learning just enough to make that work, and so on. I wasn't introduced to the "this is how to think about programming" school of thought until I'd been programming for years. But you seem to have a different problem, so perhaps the academic approach is right for you.)
posted by aneel at 8:15 PM on July 19, 2006
posted by aneel at 8:15 PM on July 19, 2006
flabdablet - agree with the majority of your post, but C doesn't hide much? Worrying About Side Issues Like Performance is important as a beginner? I'd say getting your head around (to most normal people) abstract concepts such as variables, arrays and loops was far more important. I'm sure performance issues and other frivolities didn't enter your mind for your first years using BASIC.
In many ways tinkering about in BASIC on a PET, or a BBC Micro, or other ancient computer was a way lower barrier to entry than you have now. You could start programming straight from the command line when you switched it on.
Getting a linux box and installing an unfamliar OS are massive hurdles to entry for the average person running XP and wanting to dabble in programming. Fucking around with makefiles and gcc when you can't code a Hello World would almost certainly make the average person give up (I would).
posted by toby\flat2 at 8:19 PM on July 19, 2006
In many ways tinkering about in BASIC on a PET, or a BBC Micro, or other ancient computer was a way lower barrier to entry than you have now. You could start programming straight from the command line when you switched it on.
Getting a linux box and installing an unfamliar OS are massive hurdles to entry for the average person running XP and wanting to dabble in programming. Fucking around with makefiles and gcc when you can't code a Hello World would almost certainly make the average person give up (I would).
posted by toby\flat2 at 8:19 PM on July 19, 2006
If I may tack on a subsidiary question...
I too am thinking of learning a programming language from scratch.
Would it be too ambitious to consider writing some kind of very rudimentary Firefox extension? (IE, select some text, right click, and it goes into a text file, or something like that)
posted by Brian James at 8:32 PM on July 19, 2006
I too am thinking of learning a programming language from scratch.
Would it be too ambitious to consider writing some kind of very rudimentary Firefox extension? (IE, select some text, right click, and it goes into a text file, or something like that)
posted by Brian James at 8:32 PM on July 19, 2006
I've said this at greater length on askmefi before, so I'll be brief: be the function (or class or API or table or database) you're trying to write (or design). And be reductionist.
Seriously, role play it, talk it out -- out loud if that helps: "OK, I'm function min. I get given two numbers. My job is to figure out which number is smaller, and give that number back. So I have these two numbers. Well, actually they're integers. Now what can I do with an integer?
At this point, you may or may not need to "dive down" and play the role of an integer.
Start with "Ok, I'm program main. I'm given a file, and my job is to count the whitespace in the file. Ok, I have this function called is_whitespace and it examines a character and tells me if that character is whitespace" Now write that!
bool is_whitespace( char c ) ; // this function tells me if c is whitespace
// I don't know how it works yet, but I know it is here
void foo( /* something that is a file */ ) ; // this function takes a file and counts the whitespace
// I don't know what a file looks like yet, but I can write this pseudo-code
"Ok, now if I'm function is_whitespace, I've been given this single character. Now how would I figure out if that character is whitespace. well, I know a space is whitespace." Now write that!
Etc, etc.
Be the thing you're trying to model, be aware of what you have (local variables) and what you get (parameters) and what you need to give back (return type) and what you need to do (the beginnings of your algorithm). Then ask, ok, how do I do that with what I have and what I got?
Talk it out. Gesture. Sketch. Model it with the pens and coins and crap on your desk. Abstract out what you can't immediately figure out ("Ok, I have this magic function and it does this, I just don't know yet how it does it").
Imagine the things you're modeling as actors (not stage actors, but entities that act, of course) with goals and desires: "ok, the ANSI function strcmp wants two C strings and if I give it that, it will tell me which if the first string is lexicographically prior to the second string. Ok,. so I want to give it two C strings. A C string is a (non-null) pointer, so I need to find...."
posted by orthogonality at 8:43 PM on July 19, 2006 [3 favorites]
Seriously, role play it, talk it out -- out loud if that helps: "OK, I'm function min. I get given two numbers. My job is to figure out which number is smaller, and give that number back. So I have these two numbers. Well, actually they're integers. Now what can I do with an integer?
At this point, you may or may not need to "dive down" and play the role of an integer.
Start with "Ok, I'm program main. I'm given a file, and my job is to count the whitespace in the file. Ok, I have this function called is_whitespace and it examines a character and tells me if that character is whitespace" Now write that!
bool is_whitespace( char c ) ; // this function tells me if c is whitespace
// I don't know how it works yet, but I know it is here
void foo( /* something that is a file */ ) ; // this function takes a file and counts the whitespace
// I don't know what a file looks like yet, but I can write this pseudo-code
"Ok, now if I'm function is_whitespace, I've been given this single character. Now how would I figure out if that character is whitespace. well, I know a space is whitespace." Now write that!
Etc, etc.
Be the thing you're trying to model, be aware of what you have (local variables) and what you get (parameters) and what you need to give back (return type) and what you need to do (the beginnings of your algorithm). Then ask, ok, how do I do that with what I have and what I got?
Talk it out. Gesture. Sketch. Model it with the pens and coins and crap on your desk. Abstract out what you can't immediately figure out ("Ok, I have this magic function and it does this, I just don't know yet how it does it").
Imagine the things you're modeling as actors (not stage actors, but entities that act, of course) with goals and desires: "ok, the ANSI function strcmp wants two C strings and if I give it that, it will tell me which if the first string is lexicographically prior to the second string. Ok,. so I want to give it two C strings. A C string is a (non-null) pointer, so I need to find...."
posted by orthogonality at 8:43 PM on July 19, 2006 [3 favorites]
Brian James writes "Would it be too ambitious to consider writing some kind of very rudimentary Firefox extension? (IE, select some text, right click, and it goes into a text file, or something like that)"
Just do the javascript on a web page, then in the JavaScript shell (an extension). Packaging your work in an extension is a PITA that will distract you as a newbie, and for no good reason.
posted by orthogonality at 8:46 PM on July 19, 2006
Just do the javascript on a web page, then in the JavaScript shell (an extension). Packaging your work in an extension is a PITA that will distract you as a newbie, and for no good reason.
posted by orthogonality at 8:46 PM on July 19, 2006
There is a book called Code which I read in high school before I took calculus (probably even Algebra II). It was easy to understand and really leap frogged my understanding of computers.
Stick to non-graphical programming, such as BASIC. I would use BASIC until you began to run into barriers. C#, C++ and the ilk are all great but their syntax can be somewhat obtuse if you have trouble with more basic concepts. You really can do a lot in BASIC, albeit perhaps not as efficiently with more advanced languages. I remember writing genetic algorithms in BASIC in high school and I am no prodigy programmer, nor do I program today.
Please get a "For Dummies" book or even something aimed at the teen crowd. While advanced programming concepts can be difficult I will tell you with absolute honesty you should be able to program simple programs if you have the intelligence to find AskMetafilter and post to this web site. Don't be afraid of some humility and going to the very basics instead of going after a broad spectrum of languages.
posted by geoff. at 9:04 PM on July 19, 2006
Stick to non-graphical programming, such as BASIC. I would use BASIC until you began to run into barriers. C#, C++ and the ilk are all great but their syntax can be somewhat obtuse if you have trouble with more basic concepts. You really can do a lot in BASIC, albeit perhaps not as efficiently with more advanced languages. I remember writing genetic algorithms in BASIC in high school and I am no prodigy programmer, nor do I program today.
Please get a "For Dummies" book or even something aimed at the teen crowd. While advanced programming concepts can be difficult I will tell you with absolute honesty you should be able to program simple programs if you have the intelligence to find AskMetafilter and post to this web site. Don't be afraid of some humility and going to the very basics instead of going after a broad spectrum of languages.
posted by geoff. at 9:04 PM on July 19, 2006
Everything I learned I learned by setting myself interesting tasks. I wrote a video poker game to stop my girlfriend gambling with actual money. I wrote a localised search engine because I wanted to be able to look stuff up that was in text files on my computer. I wrote something to remind me of stuff I kept forgetting. I wrote a script to check if we'd won lotto that week. I wrote an RSS feed scraper for a site that didn't have one.
None of these are of interest to you maybe, but they were of interest to me.
Larry Wall, (we're not worthy!) has said that laziness is one of the virtues of a programmer -- so, find some annoying task or inconsistency or inconvenience that bugs you and write a program to get around it.
posted by AmbroseChapel at 9:28 PM on July 19, 2006
None of these are of interest to you maybe, but they were of interest to me.
Larry Wall, (we're not worthy!) has said that laziness is one of the virtues of a programmer -- so, find some annoying task or inconsistency or inconvenience that bugs you and write a program to get around it.
posted by AmbroseChapel at 9:28 PM on July 19, 2006
devilsbrigade: OK, I was being a little hyperbolic; my claim should probably have been more like "you can't just look at a chunk of somebody else's C++ code and be confident that you'll (a) know under what circumstances it actually gets executed, or will not get executed (b) know what it does when it does get called, even if you know the C++ language itself backwards and forwards and inside out.".
And the example you use makes my point for me. As a beginner, you shouldn't be thinking of strings as Just Another Thing, if your aim is to learn to think like a programmer. Thinking like a programmer, in my opinion, is to a large extent learning to think like a CPU. As Joel notes: strings are hard. It's much easier to figure out why strings are hard - that is, to think like a programmer - if you know how they work under the hood.
A beginning C programmer who is doing the same kinds of things in C that I was doing thirty years ago in BASIC is not going to need memory management for quite some months.
And I still maintain that you need a grounding in C, if for no other reason than to appreciate properly the shortcuts that C++ does make available; and I still maintain that C, as a language, is much easier to wrap a newbie mind around that C++ will ever be, essentially because it's pretty much a subset.
Toby: finding out about performance is important to a beginner, because a beginner will be dealing with simple, little things; and with simple little projects, performance is all about algorithms, and understanding algorithms is damn near as important as understanding data structures.
Turning an old computer into a Linux box by booting the Ubuntu installer CD and clicking Next a lot is really not very tough. And what it gives you, among other things, is a command-line-based programming environment that works instead of getting in your frickin' way at every opportunity.
The point of my advice was that tinkering in BASIC is a lot fiddlier these days than it used to be; but for the kinds of little projects that I used to code up on the PET, you don't need makefiles or any of that - you need the same skills you used to make hello-world.c work, which means you need to know how to type
at a command prompt. It's really not that much harder than typing RUN, and the Kernighan and Pike book I recommended makes it all make sense anyway.
posted by flabdablet at 9:31 PM on July 19, 2006
And the example you use makes my point for me. As a beginner, you shouldn't be thinking of strings as Just Another Thing, if your aim is to learn to think like a programmer. Thinking like a programmer, in my opinion, is to a large extent learning to think like a CPU. As Joel notes: strings are hard. It's much easier to figure out why strings are hard - that is, to think like a programmer - if you know how they work under the hood.
A beginning C programmer who is doing the same kinds of things in C that I was doing thirty years ago in BASIC is not going to need memory management for quite some months.
And I still maintain that you need a grounding in C, if for no other reason than to appreciate properly the shortcuts that C++ does make available; and I still maintain that C, as a language, is much easier to wrap a newbie mind around that C++ will ever be, essentially because it's pretty much a subset.
Toby: finding out about performance is important to a beginner, because a beginner will be dealing with simple, little things; and with simple little projects, performance is all about algorithms, and understanding algorithms is damn near as important as understanding data structures.
Turning an old computer into a Linux box by booting the Ubuntu installer CD and clicking Next a lot is really not very tough. And what it gives you, among other things, is a command-line-based programming environment that works instead of getting in your frickin' way at every opportunity.
The point of my advice was that tinkering in BASIC is a lot fiddlier these days than it used to be; but for the kinds of little projects that I used to code up on the PET, you don't need makefiles or any of that - you need the same skills you used to make hello-world.c work, which means you need to know how to type
gcc -o hello-world hello-world.c
./hello-worldat a command prompt. It's really not that much harder than typing RUN, and the Kernighan and Pike book I recommended makes it all make sense anyway.
posted by flabdablet at 9:31 PM on July 19, 2006
toby\flat2 writes "I usually get beaten for suggesting this, but I really do feel Flash, and it's programming language, Actionscript, are a really good way to get into programming for people who have started late or need a more visual and immediate way of seeing their efforts displayed.
I'll second this... Actionscript is a wonderful first programming language... It's hard to find things to do with other programming languages and apply them to something you would actually want to do. But with Actionscript, moving something across the screen is pretty cool, and it involves loops... Then if you want to take commands by a text input box, you can learn string parsing. Having objects interact with each other involves functions and you can get pretty advanced. Granted, you won't find malloc anywhere, but you'll still be thinking like a programmer, and you'll HAVE to think object-orientedly (this is a good thing), because everything is an object, and you can physically see them as objects.
I've wanted to write an introduction to programming that involves actionscript for a very long time, I hope I can get around to it sometime soon.
posted by hatsix at 10:34 PM on July 19, 2006
I'll second this... Actionscript is a wonderful first programming language... It's hard to find things to do with other programming languages and apply them to something you would actually want to do. But with Actionscript, moving something across the screen is pretty cool, and it involves loops... Then if you want to take commands by a text input box, you can learn string parsing. Having objects interact with each other involves functions and you can get pretty advanced. Granted, you won't find malloc anywhere, but you'll still be thinking like a programmer, and you'll HAVE to think object-orientedly (this is a good thing), because everything is an object, and you can physically see them as objects.
I've wanted to write an introduction to programming that involves actionscript for a very long time, I hope I can get around to it sometime soon.
posted by hatsix at 10:34 PM on July 19, 2006
Have you tried taking a class? I had a hell of a time learning to program until I took a cheap class at the local community college. That led into several more cheap programming classes and then into an actual job programming! Nothing beats classwork and a real-live human being to answer questions.
posted by jdroth at 10:56 PM on July 19, 2006
posted by jdroth at 10:56 PM on July 19, 2006
OK, I'm an engineer and CS postgrad who teaches advanced C++ to professionals and Java to first year CS students and I'm telling you, please don't start with C++. Ignore those who tell you that it's a dog breakfast, it's great. It's just not a good choice of first language.
C isn't much better or worse: there's less to learn but it can be quite arcane. If you start with these languages, I can guarantee you'll write programs that should work (to the best of your understanding) but just crash randomly because there's some gotcha you haven't learnt about yet. There are many, many gotchas.
My recommendation is to start with Java and for the same reason that someone above recommended you don't use it: it is strongly typed. Strong typing is your friend: it tells you when you've done something invalid and it tells you as early as possible. It won't try to figure out what you meant, it forces you to explicitly state what you meant, which is a good thing. Magical conversion of stuff is bad because it makes it much more difficult to reason about program behaviour.
My only reservation with starting on Java is that you do need to pick up a fair bit of object-oriented stuff; starting with an imperative language is easier. However, the documentation is excellent and there are more tutorials and books available for Java than you can poke a stick at.
I recommend getting not just a language-tutorial book but a first-year comp sci textbook that will actually teach you the process of programming and how algorithm design works. That's much more important than any particular language and I cannot emphasise it enough. Go to the websites of a bunch of nearby respectable engineering universities and look up their CS web pages; each will list their required texts for each subject. Check out (ie, read for half an hour) all their required and recommended texts and buy the one that looks most interesting.
Another thing you can do with university web pages is download the assignment questions and try to solve the problems that we give the students. This is good for the basics but will soon bore you.
Don't bother much with book examples, write something you find interesting. People here have given examples of stuff they've written but the point is that it must be fun. I started out writing fractal generators (ridiculously easy in Java because of its graphical capability) and computer games, so I'd recommend you start there.
Ada and Pascal are great languages for learning the concepts of imperative programming (selection (if), iteration (loops) and functions); they just don't have a lot of relevance these days and it might be difficult to find decent compilers to work on your computer.
posted by polyglot at 11:02 PM on July 19, 2006
C isn't much better or worse: there's less to learn but it can be quite arcane. If you start with these languages, I can guarantee you'll write programs that should work (to the best of your understanding) but just crash randomly because there's some gotcha you haven't learnt about yet. There are many, many gotchas.
My recommendation is to start with Java and for the same reason that someone above recommended you don't use it: it is strongly typed. Strong typing is your friend: it tells you when you've done something invalid and it tells you as early as possible. It won't try to figure out what you meant, it forces you to explicitly state what you meant, which is a good thing. Magical conversion of stuff is bad because it makes it much more difficult to reason about program behaviour.
My only reservation with starting on Java is that you do need to pick up a fair bit of object-oriented stuff; starting with an imperative language is easier. However, the documentation is excellent and there are more tutorials and books available for Java than you can poke a stick at.
I recommend getting not just a language-tutorial book but a first-year comp sci textbook that will actually teach you the process of programming and how algorithm design works. That's much more important than any particular language and I cannot emphasise it enough. Go to the websites of a bunch of nearby respectable engineering universities and look up their CS web pages; each will list their required texts for each subject. Check out (ie, read for half an hour) all their required and recommended texts and buy the one that looks most interesting.
Another thing you can do with university web pages is download the assignment questions and try to solve the problems that we give the students. This is good for the basics but will soon bore you.
Don't bother much with book examples, write something you find interesting. People here have given examples of stuff they've written but the point is that it must be fun. I started out writing fractal generators (ridiculously easy in Java because of its graphical capability) and computer games, so I'd recommend you start there.
Ada and Pascal are great languages for learning the concepts of imperative programming (selection (if), iteration (loops) and functions); they just don't have a lot of relevance these days and it might be difficult to find decent compilers to work on your computer.
posted by polyglot at 11:02 PM on July 19, 2006
Broadly I'm seeing two approaches advocated here - learning through experience, and learning through a structured theoretical approach. Can I recommend both? I started out self-taught in BASIC in the 80s, and studied comp sci in the 90s. I had so many aha! moments at university that my fellow students didn't, because I could relate what was being taught to problems I had already banged my head against. I also really wished I could travel back in time and give teenage me some programming advice. So do both. Pick a problem and hack on it, AND start building up a library of CS texts. Skim them, think about the things that you can make sense of, and pick them up regularly - then they will make more sense.
And let me put a vote in for Python.
posted by i_am_joe's_spleen at 12:07 AM on July 20, 2006
And let me put a vote in for Python.
posted by i_am_joe's_spleen at 12:07 AM on July 20, 2006
I will 3rd Python as my language of choice.
However most intro to programming stuff is oriented towards C++/Java. Stay away from Basic/VB (not particularly useful in real world settings these days), Perl (difficult syntax for a first time language), and assembly at first. Java is the best language to learn first in my opinion because it takes care of so much for you and you can focus on actually programming something, and it is open source motivated and the library documentation and great tutorials are online at Sun's website. I took an online Java class last semester and after the 2nd assignment I sold back my book to Amazon and looked up all my questions @ Sun.
Also, check out your local community college as they probably offer a variety of intro programming classes and language classes for relatively cheap. It will probably be C++ or Java, as these are the classes traditionally taught first and used for a wide variety of applications programming. It helps to have someone right there to look at your code and show you what you are doing wrong and what could be implemented differently/better.
Once again, pick a project you are interested in and start building some stuff towards it. You will be more motivated and you are more likely to learn how to actually build something useful from scratch than just copying examples will ever teach you.
posted by sophist at 2:16 AM on July 20, 2006
However most intro to programming stuff is oriented towards C++/Java. Stay away from Basic/VB (not particularly useful in real world settings these days), Perl (difficult syntax for a first time language), and assembly at first. Java is the best language to learn first in my opinion because it takes care of so much for you and you can focus on actually programming something, and it is open source motivated and the library documentation and great tutorials are online at Sun's website. I took an online Java class last semester and after the 2nd assignment I sold back my book to Amazon and looked up all my questions @ Sun.
Also, check out your local community college as they probably offer a variety of intro programming classes and language classes for relatively cheap. It will probably be C++ or Java, as these are the classes traditionally taught first and used for a wide variety of applications programming. It helps to have someone right there to look at your code and show you what you are doing wrong and what could be implemented differently/better.
Once again, pick a project you are interested in and start building some stuff towards it. You will be more motivated and you are more likely to learn how to actually build something useful from scratch than just copying examples will ever teach you.
posted by sophist at 2:16 AM on July 20, 2006
I try to get beginning programmers to explicitly markup their programs in pseudocode at an early stage, just to get into the habit of early prototyping. Most people feel foolish doing this at first, but as it begins to uncover cognitive issues in understanding the procedural flow (flow of control) of the task, or needs for algorithms or sub-procedures, the value of the pseudocode prototype becomes clear. Next, I try to get them to analyze the pseudocode to identify as many familiar techniques and procedures as possible, that it contains (where are all the loops? What kind of loops are they? What are the loop conditions, what are the increments, what are the exit tests? Etc.). I have them add these observations as "comments" in the pseudocode. Next, I ask them to review the pseudocode prototype for modules and techniques they may already know (sorts, arrays, etc.) and add these observations as pseudocode comments, too. This step helps them to see that this program will build on their existing knowledge in some areas, but may call for research and new learning in others.
Once there is a basic definition of the program in pseudocode, I suggest they do a detailed conceptual walkthrough, especially if it is a complicated program, or a team project, not unlike orthogonality has suggested. Finally, before finishing with the pseudocode prototype, I ask them to explicitly label the prototype with the real function and variable names they intend to use in the actual program, as much as possible, and to try to make this exercise a coherent namespace. This final prototyping step vastly reduces confusion when beginning the actual coding.
With the initial program design completed in pseudocode, I next ask the new programmers to concentrate on coding whatever low level modules they can in the target language of choice. While doing this, they should concentrate only on coding and testing discrete modules, and they are responsible for coding the module, developing the testing, and debugging their code, as much as possible. Ideally, their focus while doing this is purely on creating discrete functions or procedures in the language they are trying to learn, with as little design and algorithmic distraction as possible.
Breaking things up like this seems to help new programmers avoid design panic, and prevents them from getting sidetracked in gumption traps of their own creation. It's a fairly natural method of extending what they know, with new learning, too.
posted by paulsc at 3:45 AM on July 20, 2006
Once there is a basic definition of the program in pseudocode, I suggest they do a detailed conceptual walkthrough, especially if it is a complicated program, or a team project, not unlike orthogonality has suggested. Finally, before finishing with the pseudocode prototype, I ask them to explicitly label the prototype with the real function and variable names they intend to use in the actual program, as much as possible, and to try to make this exercise a coherent namespace. This final prototyping step vastly reduces confusion when beginning the actual coding.
With the initial program design completed in pseudocode, I next ask the new programmers to concentrate on coding whatever low level modules they can in the target language of choice. While doing this, they should concentrate only on coding and testing discrete modules, and they are responsible for coding the module, developing the testing, and debugging their code, as much as possible. Ideally, their focus while doing this is purely on creating discrete functions or procedures in the language they are trying to learn, with as little design and algorithmic distraction as possible.
Breaking things up like this seems to help new programmers avoid design panic, and prevents them from getting sidetracked in gumption traps of their own creation. It's a fairly natural method of extending what they know, with new learning, too.
posted by paulsc at 3:45 AM on July 20, 2006
I learned how to program mostly using Pascal (~20 years ago), and I still highly recommend it as a teaching language. It's simple enough that you can really focus on learning the algorithms instead of fighting with the syntax, but it's similar enough to other modern languages that you'll have no trouble making the transition once you're ready to handle other concepts. There appear to be several pascal compilers for linux (none of which I've tried), including a GNU one.
Second, learning the algorithms is important, but it's also really important to understand how the computer runs the algorithms. A lot of things didn't click for me until I got some experience with digital logic and basic circuit design.
posted by Caviar at 6:53 AM on July 20, 2006
Second, learning the algorithms is important, but it's also really important to understand how the computer runs the algorithms. A lot of things didn't click for me until I got some experience with digital logic and basic circuit design.
posted by Caviar at 6:53 AM on July 20, 2006
Wow, lots of great answers. I hope my suggestion helps. What works for me is lots of practice with real world problems. They need to be small, and introduce one new concept to you each time.
One website that I really like is Top Coder. If you sign up, you can get access to the list of algorythms that have been part of contests. The really cool thing is that you can sort the list in order of the number of people that completed the challenges successfully. In other words, you sort the list of 1,000ish problems from easiest to hardest. I just started at the easiest problem, and worked through them one at a time.
Even cooler, you can see the solution by the fastest coder, so you can understand the right way to do it after you're stumped. The solutions can be done in Java, C++, or Visual Basic, so can see the answers in each language.
The only problem is that they don't use the best coding style. It's a speed challenge, so you can learn some bad habits.
Set up Eclipse on your computer if you haven't already. Drop me an email and I can give you the starting code to so that you can start developing algorythms. Once you've done a few, the Java books will start making much more sense.
posted by fcain at 7:05 AM on July 20, 2006
One website that I really like is Top Coder. If you sign up, you can get access to the list of algorythms that have been part of contests. The really cool thing is that you can sort the list in order of the number of people that completed the challenges successfully. In other words, you sort the list of 1,000ish problems from easiest to hardest. I just started at the easiest problem, and worked through them one at a time.
Even cooler, you can see the solution by the fastest coder, so you can understand the right way to do it after you're stumped. The solutions can be done in Java, C++, or Visual Basic, so can see the answers in each language.
The only problem is that they don't use the best coding style. It's a speed challenge, so you can learn some bad habits.
Set up Eclipse on your computer if you haven't already. Drop me an email and I can give you the starting code to so that you can start developing algorythms. Once you've done a few, the Java books will start making much more sense.
posted by fcain at 7:05 AM on July 20, 2006
Programming seems hard to you because.........wait for it........programming IS hard!
Many books and tutorials concentrate on the nuts and bolts of the languages, and not enough on how to design a program. paulsc and orthogonality mention a powerful tool, pseudocode. Pseudocode isn't just some sort of cartoon sketch of a program, it is a tried-and-tested way to sort out a sensible way to code a program. Use it it figure out the steps the program needs to take to solve its given problem.
Sorry I haven't time today to check the web for a good tutorial. Go and find one that suits you. It should talk about different levels of pseudocode -- you should first write a high-level version and then a more detailed version breaking down the high-level broad steps into operations you can program. Anything that expects you to write the complete pseudocode for a program in one pass is merely replicating the problem of thnking out the steps.
posted by Idcoytco at 7:41 AM on July 20, 2006
Many books and tutorials concentrate on the nuts and bolts of the languages, and not enough on how to design a program. paulsc and orthogonality mention a powerful tool, pseudocode. Pseudocode isn't just some sort of cartoon sketch of a program, it is a tried-and-tested way to sort out a sensible way to code a program. Use it it figure out the steps the program needs to take to solve its given problem.
Sorry I haven't time today to check the web for a good tutorial. Go and find one that suits you. It should talk about different levels of pseudocode -- you should first write a high-level version and then a more detailed version breaking down the high-level broad steps into operations you can program. Anything that expects you to write the complete pseudocode for a program in one pass is merely replicating the problem of thnking out the steps.
posted by Idcoytco at 7:41 AM on July 20, 2006
Wow...no one has mentioned Bruce Eckel and his Thinking in ... books.
Thinking in Java is free, as are the code examples. I highly recommend Bruce's books. When I took a C++ course at Stanford, Thinking in C++ was THE text.
posted by toastchee at 7:47 AM on July 20, 2006
Thinking in Java is free, as are the code examples. I highly recommend Bruce's books. When I took a C++ course at Stanford, Thinking in C++ was THE text.
posted by toastchee at 7:47 AM on July 20, 2006
I am not an extremely skilled coder, but all those who support defining a simple problem and then solving it with a program as the best way to learn have my agreement. Also, the poignant guide explains some programming concepts in a memorable way, albeit in the context of Ruby, a language that is not exactly industry-standard.
posted by thedaniel at 10:18 AM on July 20, 2006
posted by thedaniel at 10:18 AM on July 20, 2006
The book that made me love programming is Structure and Interpretation of Computer Programs. Take a Scheme course, or any other functional programming course (like Haskell). Functional programming, even if it doesn't lead directly to techniques you use, will teach you what programming is about.
posted by fleacircus at 12:45 PM on July 20, 2006
posted by fleacircus at 12:45 PM on July 20, 2006
Try the "Numerical Recipes" books for algorithms, now online.
posted by 445supermag at 1:04 PM on July 20, 2006
posted by 445supermag at 1:04 PM on July 20, 2006
I'd try a different approach. Find an art you're passionate about, and then see if there's an associated programming language. Music is a good example. You could try learning SuperCollider or Max/MSP or CSound which all vary in difficulty. A lot of the folks using SuperCollider are musicians who swear they're not programmers, yet they're busting out some seriously cool code (and learning other languages in the process).
posted by bizack at 2:37 PM on July 20, 2006 [1 favorite]
posted by bizack at 2:37 PM on July 20, 2006 [1 favorite]
It's a bit of a chicken-and-egg situation - you can't learn to "think like a programmer" until you learn to program, and actually "learning to program" can seem to be a distant goal until you start thinking like a programmer.
If you really are starting from scratch, with no knowledge of languages or how it all fits together, then there's nothing wrong with parroting examples - but try and understand what each expression in the example is doing. Once that clicks - and it may take a while, but something will eventually click with you - then you can start learning from books and courses. Up to that point, books and courses are good at teaching you the right way and the wrong way to do various things - but until then, you won't understand why the right way is right, the wrong way is wrong, and when the wrong way is the right solution ;-)
Personal suggestions:
Start with JavaScript (or its close Flash cousin, ActionScript). Like good ol' interpreted BASIC it's a simple language and, running in a browser, can give immediate feedback. Unlike good ol' interpreted BASIC, it's a (relatively) clean and well-structured language that doesn't teach too many bad programming habits. It can also take you from "Hello World" to 10,000 lines of OO code without breaking your PC.
Definitely, set yourself a task. My favourite was to learn a new language by writing a version of the old "Trek" game. I've done that in BASIC, C, C++, ObjC, Pascal, Delphi, VB, JavaScript, PHP, etc, and they range from simple command-line examples to full-blown multiwindow graphical extravaganzas. Lots of good basic concepts to learn and problems to solve there, too - user input, string handling, bounds checking, array use and manipulation, vector mathematics, etc.
(Not that I'm a good programmer - it's just as much an art as a science, and I'm also no artist - but I can at least code if and when I have to.)
posted by Pinback at 9:18 PM on July 20, 2006
If you really are starting from scratch, with no knowledge of languages or how it all fits together, then there's nothing wrong with parroting examples - but try and understand what each expression in the example is doing. Once that clicks - and it may take a while, but something will eventually click with you - then you can start learning from books and courses. Up to that point, books and courses are good at teaching you the right way and the wrong way to do various things - but until then, you won't understand why the right way is right, the wrong way is wrong, and when the wrong way is the right solution ;-)
Personal suggestions:
Start with JavaScript (or its close Flash cousin, ActionScript). Like good ol' interpreted BASIC it's a simple language and, running in a browser, can give immediate feedback. Unlike good ol' interpreted BASIC, it's a (relatively) clean and well-structured language that doesn't teach too many bad programming habits. It can also take you from "Hello World" to 10,000 lines of OO code without breaking your PC.
Definitely, set yourself a task. My favourite was to learn a new language by writing a version of the old "Trek" game. I've done that in BASIC, C, C++, ObjC, Pascal, Delphi, VB, JavaScript, PHP, etc, and they range from simple command-line examples to full-blown multiwindow graphical extravaganzas. Lots of good basic concepts to learn and problems to solve there, too - user input, string handling, bounds checking, array use and manipulation, vector mathematics, etc.
(Not that I'm a good programmer - it's just as much an art as a science, and I'm also no artist - but I can at least code if and when I have to.)
posted by Pinback at 9:18 PM on July 20, 2006
Okay, I'm late to this thread and it's already filled with tons of great advice, but I wanted to chime in to echo jdroth's suggestion of taking an introductory comp sci class at a local community college.. I struggled for a long time to learn programming from books like all my friends had done, and felt all the same things that you describe. I eventually came to the (wrong) conclusion that I just wasn't cut out for programming.
Years later, I took an introductory computer science class on a whim, fully prepared to fail because I wouldn't be able to "get" it. The classroom setting, structured assignments and regular feedback helped me get over the initial learning curve, and gave me small goals that I knew were reasonable for someone first learning to program... At some point that semester I "got" whatever it was I didn't get before (I'm still not sure what it was, but it was something!), and it even turned out that I had a knack for it. So, if you remain frustrated with the books and websites, don't lose hope!
posted by everybody polka at 10:29 PM on July 21, 2006
Years later, I took an introductory computer science class on a whim, fully prepared to fail because I wouldn't be able to "get" it. The classroom setting, structured assignments and regular feedback helped me get over the initial learning curve, and gave me small goals that I knew were reasonable for someone first learning to program... At some point that semester I "got" whatever it was I didn't get before (I'm still not sure what it was, but it was something!), and it even turned out that I had a knack for it. So, if you remain frustrated with the books and websites, don't lose hope!
posted by everybody polka at 10:29 PM on July 21, 2006
Thinking in Java is free, as are the code examples.
Not the 4th edition.
posted by bingo at 1:07 PM on July 22, 2006
Not the 4th edition.
posted by bingo at 1:07 PM on July 22, 2006
Computer Science: An Overview. I asked around all the people here who teach our first year course and this is the only book they could agree upon. My question started a half-hour whinge session about the paucity of intro computer science and algorithm books currently on the market, but that's for another time.
It's not so much a "how to program" book but deals more with the fundamentals of computation.
posted by polyglot at 6:36 PM on July 25, 2006
It's not so much a "how to program" book but deals more with the fundamentals of computation.
posted by polyglot at 6:36 PM on July 25, 2006
This thread is closed to new comments.
I would suggest finding a project, such as developing a certain application, and learning the language by stumbling designing it. With your first application you don't really need a solid concept of programming style, or patterns.
I would start with a simple scripting language such as PHP/Python/Perl that gives you instant results without having to work with compiler errors and such.
posted by SirStan at 6:59 PM on July 19, 2006