Compiler, instruction,... Whats your function?
January 29, 2008 4:20 PM Subscribe
I want to conquer my apparent inability to comprehend or write code. I'm looking for stories (or real life applicable tips from those of you who write code for a living) where you had the "A HA, I understand this finally" epiphany moment. I realize this might sound like an overly generic question, which is why there is ....
For the past 10 years or so, my computer background has been all support type jobs, mainly Windows and system/network administration. There have been a few times when I've been asked to hack some code, but it was all pre-existing HTML, XML or small scripts and I was able to figure it out.
Fast forward to now. The new job I've had for approx 6 months at an ISP where most of the systems are Unix (BSD) based and there is a lot of custom perl scripting . I've tried over the past several years to explore the code writing arena (java, perl, php, css,etc) but I've never been able to make any significant headway. (nothing beyond "hello world")
The problem I have is code writing is severely intimidating to me. I've explored our system scripts folder.. and had co-workers attempt to explain the inner workings of the different scripts to me and it literally gives me a headache. Its like looking at a page of klingon writing. My brain seizes up. Seg fault. Game over. (its also very intimidating to me that other people are able to (seemingly) just walk right over and pick up a book and learn code in a weekend.
So I've come to the conclusion(s) that:
1.) I'm either missing something fundamentally crucial to understanding
or
2.) My brain isnt wired that way (which explains the headaches) and I should instead be investing my time in things more abstract and visual.
or
3.) Coders are very bad teachers
or
4.) ... ????
Its very frustrating to be so good at so many other things in my life, but have something like this elude me. I would very much enjoy the feeling of accomplishment of being able to code something sweet enough that someone else comments "Hey, thats pretty awesome"
Questions, Comments?.. I have the night off so I'll be here to answer them.
For the past 10 years or so, my computer background has been all support type jobs, mainly Windows and system/network administration. There have been a few times when I've been asked to hack some code, but it was all pre-existing HTML, XML or small scripts and I was able to figure it out.
Fast forward to now. The new job I've had for approx 6 months at an ISP where most of the systems are Unix (BSD) based and there is a lot of custom perl scripting . I've tried over the past several years to explore the code writing arena (java, perl, php, css,etc) but I've never been able to make any significant headway. (nothing beyond "hello world")
The problem I have is code writing is severely intimidating to me. I've explored our system scripts folder.. and had co-workers attempt to explain the inner workings of the different scripts to me and it literally gives me a headache. Its like looking at a page of klingon writing. My brain seizes up. Seg fault. Game over. (its also very intimidating to me that other people are able to (seemingly) just walk right over and pick up a book and learn code in a weekend.
So I've come to the conclusion(s) that:
1.) I'm either missing something fundamentally crucial to understanding
or
2.) My brain isnt wired that way (which explains the headaches) and I should instead be investing my time in things more abstract and visual.
or
3.) Coders are very bad teachers
or
4.) ... ????
Its very frustrating to be so good at so many other things in my life, but have something like this elude me. I would very much enjoy the feeling of accomplishment of being able to code something sweet enough that someone else comments "Hey, thats pretty awesome"
Questions, Comments?.. I have the night off so I'll be here to answer them.
Code is frequently easier to write than to read, so trying to understand it by reading some hacky scripts someone else wrote is not a good way to start. There are many, many bad coders in the world, so it's not surprising that a lot of them would be bad teachers.
Of the languages you mentioned, CSS is not really a programming language. Java can be a little difficult, and PHP will rot your brain. You might want to give Python a try.
posted by grouse at 4:33 PM on January 29, 2008
Of the languages you mentioned, CSS is not really a programming language. Java can be a little difficult, and PHP will rot your brain. You might want to give Python a try.
posted by grouse at 4:33 PM on January 29, 2008
These two tips may help
1. To learn to code you have to follow the rules of learning anything. That is, you have to observe, think, do, and repeat. Find people who code really well. Watch how they do it, and read their code. Ask them questions. Come up with problems you want to solve. Try to solve those problems in code using what you've observed and read. Then repeat.
It's perfectly fine to keep rewriting the same code over and over again, just to see the different ways you can do.
2. You have to have an interest (and hopefully a passion) for coding. Coding has to make you extremely happy. You'll only be able to get so far by coding for a purpose. Once coding becomes fun in itself, you'll rapidly improve.
posted by brandnew at 4:34 PM on January 29, 2008 [1 favorite]
1. To learn to code you have to follow the rules of learning anything. That is, you have to observe, think, do, and repeat. Find people who code really well. Watch how they do it, and read their code. Ask them questions. Come up with problems you want to solve. Try to solve those problems in code using what you've observed and read. Then repeat.
It's perfectly fine to keep rewriting the same code over and over again, just to see the different ways you can do.
2. You have to have an interest (and hopefully a passion) for coding. Coding has to make you extremely happy. You'll only be able to get so far by coding for a purpose. Once coding becomes fun in itself, you'll rapidly improve.
posted by brandnew at 4:34 PM on January 29, 2008 [1 favorite]
Many programming books assume that you already know a language or two, and have a firm grasp on all the basic concepts. Once those basic concepts are in your brain, picking up a new language tends to be pretty simple.
There is a huge amount of debate about what languages are best for beginners, and I won't be surprised if this thread heads that direction. I did a quick google and came up with this free book called "Learning to Program." (Warning: Really ugly website). It has good amazon reviews, so perhaps it will help you out.
As an aside, HTML and XML are NOT programming languages, they're markup languages, made for a very different purpose than programming languages like C, Perl, Python, etc.
posted by jjb at 4:35 PM on January 29, 2008
There is a huge amount of debate about what languages are best for beginners, and I won't be surprised if this thread heads that direction. I did a quick google and came up with this free book called "Learning to Program." (Warning: Really ugly website). It has good amazon reviews, so perhaps it will help you out.
As an aside, HTML and XML are NOT programming languages, they're markup languages, made for a very different purpose than programming languages like C, Perl, Python, etc.
posted by jjb at 4:35 PM on January 29, 2008
Well, there are many, many approaches to getting an understanding of programming, and I have no idea which is best for you, but one thing you can try is to break it down into parts you do understand.
Do not try to understand an entire script. Rather, take a script (the smaller and simpler the better) to a testbed, run it, and think about some simple aspect of its behavior you'd like to change. Try altering the most understandable part of the script or whatever draws your eye first. Make the change to it simple (maybe just change a string value or comment out a line), and see what happens when you run it. Does it break? How does it break? Does some of the displayed console text change? Change it back and verify that it works again.
Then, tweak something else and repeat the cycle. This'll get you a feel for how a script works. The more you are able to predictable alter the script, the more confidence you'll have about it. Once you have an idea about how it works, talk it over with whomever wrote it and try to get him to answer specific questions about it.
This is more or less how I do things when I have to modify a program or script that's in a language that I don't have much experience with. It usually works for simple changes.
posted by ignignokt at 4:41 PM on January 29, 2008
Do not try to understand an entire script. Rather, take a script (the smaller and simpler the better) to a testbed, run it, and think about some simple aspect of its behavior you'd like to change. Try altering the most understandable part of the script or whatever draws your eye first. Make the change to it simple (maybe just change a string value or comment out a line), and see what happens when you run it. Does it break? How does it break? Does some of the displayed console text change? Change it back and verify that it works again.
Then, tweak something else and repeat the cycle. This'll get you a feel for how a script works. The more you are able to predictable alter the script, the more confidence you'll have about it. Once you have an idea about how it works, talk it over with whomever wrote it and try to get him to answer specific questions about it.
This is more or less how I do things when I have to modify a program or script that's in a language that I don't have much experience with. It usually works for simple changes.
posted by ignignokt at 4:41 PM on January 29, 2008
"The more you are able to predictably alter..." I meant.
posted by ignignokt at 4:42 PM on January 29, 2008
posted by ignignokt at 4:42 PM on January 29, 2008
some people code well, some don't
some people do math well, some don't
some people write well, some don't
some people can sell you a refrigerator in Antarctica, some couldn't sell a bottle of water to a man dying of thirst
most of these folks who do those things well are not the same as the people who do the other things well
do not worry about this stuff, please
posted by caddis at 4:46 PM on January 29, 2008
some people do math well, some don't
some people write well, some don't
some people can sell you a refrigerator in Antarctica, some couldn't sell a bottle of water to a man dying of thirst
most of these folks who do those things well are not the same as the people who do the other things well
do not worry about this stuff, please
posted by caddis at 4:46 PM on January 29, 2008
Yes, you're going about it backwards. *nix startup scripts are notoriously impossible to understand. There is a lot of shorthand involved.
Pickup a classic text like Kernighan & Ritchie "The C Programming Language". Or even find a way to learn and use BASIC. Its point is to be an easy, beginners programming language.
But, ultimately, all programming (and scripts and markups) can be broken down to rigid flow-charts. Understand how to break a task down into an algorithm (step by step procedure), and any language will be far easier.
posted by gjc at 4:52 PM on January 29, 2008
Pickup a classic text like Kernighan & Ritchie "The C Programming Language". Or even find a way to learn and use BASIC. Its point is to be an easy, beginners programming language.
But, ultimately, all programming (and scripts and markups) can be broken down to rigid flow-charts. Understand how to break a task down into an algorithm (step by step procedure), and any language will be far easier.
posted by gjc at 4:52 PM on January 29, 2008
Response by poster: Chrismear:
"What's stopped you from progressing further down the road of self-learning using tutorials and the like?"
What stopped me is that all the various books and tutorials I was reading seemed to go from Chapter 1: Hello World (very easy stuff)... to Chapter 2 : Introducing functions and modules and etc,etc (crazy insane difficult ) There didnt seem to be any middle ground, or any easy step by step build up . Coding instruction seems to be built upon the mantra of starting at the small granular level and working up, but I'm a very visual conceptual person and I learn better by knowing what the goal is and extrapolating backwards (taking the big problem and breaking it down into smaller more manageable chunks, accomplishing each chunk and stringing them all together for the big goal.
The other thing I find difficult about coding is that there are a lot of different tutorials and instructions on how to learn different languages, but not very good explanation WHY. For example, "Functions are coded this way and use these 20 different modifiers/switches, try them for yourself!!!"... that kind of instruction leaves me with a blank feeling. HOW do I "try them for myself?"... I get that the 20 different modifiers/switchs can be used to do 20 different things, but give me real world examples. something I can relate to.
It would seem to me that a better way to teach would be to to do it like this:
Chapter 1 : our goal is a simple "hello world" program, here is how we do it.
Chapter 2: a slightly more difficult program that says "hello world" in your choice of language
Chapter 3: a slightly more difficult program that ......etc
An exact stated goal for each chapter.. and clear, comprehensive explanations about why you would use certain modules or functions over choosing others. Perhaps even ending each chapter with real world examples of similar sized programs accomplishing similar things.
posted by jmnugent at 4:55 PM on January 29, 2008
"What's stopped you from progressing further down the road of self-learning using tutorials and the like?"
What stopped me is that all the various books and tutorials I was reading seemed to go from Chapter 1: Hello World (very easy stuff)... to Chapter 2 : Introducing functions and modules and etc,etc (crazy insane difficult ) There didnt seem to be any middle ground, or any easy step by step build up . Coding instruction seems to be built upon the mantra of starting at the small granular level and working up, but I'm a very visual conceptual person and I learn better by knowing what the goal is and extrapolating backwards (taking the big problem and breaking it down into smaller more manageable chunks, accomplishing each chunk and stringing them all together for the big goal.
The other thing I find difficult about coding is that there are a lot of different tutorials and instructions on how to learn different languages, but not very good explanation WHY. For example, "Functions are coded this way and use these 20 different modifiers/switches, try them for yourself!!!"... that kind of instruction leaves me with a blank feeling. HOW do I "try them for myself?"... I get that the 20 different modifiers/switchs can be used to do 20 different things, but give me real world examples. something I can relate to.
It would seem to me that a better way to teach would be to to do it like this:
Chapter 1 : our goal is a simple "hello world" program, here is how we do it.
Chapter 2: a slightly more difficult program that says "hello world" in your choice of language
Chapter 3: a slightly more difficult program that ......etc
An exact stated goal for each chapter.. and clear, comprehensive explanations about why you would use certain modules or functions over choosing others. Perhaps even ending each chapter with real world examples of similar sized programs accomplishing similar things.
posted by jmnugent at 4:55 PM on January 29, 2008
nth-ing Trying to learn perl or programming in general from someone else's very clever hacked together scripts and programs is a surefire way to get a headache.
posted by jjb at 4:55 PM on January 29, 2008
posted by jjb at 4:55 PM on January 29, 2008
Find some on-line courses and take them. Find a nice intro to C++ class. Perl is the great Satan and even experienced programmers groan when trying to real perl written by others.
Start here?
posted by jeffamaphone at 4:56 PM on January 29, 2008
Start here?
posted by jeffamaphone at 4:56 PM on January 29, 2008
Response by poster: gjc
"But, ultimately, all programming (and scripts and markups) can be broken down to rigid flow-charts. Understand how to break a task down into an algorithm (step by step procedure), and any language will be far easier."
Funny you should mention that. One of the projects I'm working on at work is upgrading our Nagios network monitoring tool. Over the past few months many people have tried to explain the configuration files to me without any success.
Then about a week ago I found this:
http://nagios.sourceforge.net/download/contrib/documentation/misc/config_diagrams/nagios-config.png
And it was like pure joy.
Examples like this are what keep me wondering if I'm doomed to be forever a visual person.
posted by jmnugent at 5:00 PM on January 29, 2008 [1 favorite]
"But, ultimately, all programming (and scripts and markups) can be broken down to rigid flow-charts. Understand how to break a task down into an algorithm (step by step procedure), and any language will be far easier."
Funny you should mention that. One of the projects I'm working on at work is upgrading our Nagios network monitoring tool. Over the past few months many people have tried to explain the configuration files to me without any success.
Then about a week ago I found this:
http://nagios.sourceforge.net/download/contrib/documentation/misc/config_diagrams/nagios-config.png
And it was like pure joy.
Examples like this are what keep me wondering if I'm doomed to be forever a visual person.
posted by jmnugent at 5:00 PM on January 29, 2008 [1 favorite]
This sounds like a classic issue of someone unwilling to go through the painful process of learning and expecting to 'just figure it out.' Why did you stop at 'hello world?' From there you should be progressing to learning to automate simple tasks like installing software. Learn some AutoIT and automate some task. Stay in the windows world of simple tasks. Now go take a java class and learn what OOP is. Now do some web development on the side and learn how to do very simple things in javasctipt. Maybe take another class on how to do database driven dynamic page development. Now take a linux sysadmins class that focuses on perl. In two years you might catch up. If youre unwilling to do this work then you'll never catch one.
Start small. Develop a lot of patience and realize that systems and programming are two very, very different skills. This is like a plumber complaining on the dififculty of municipal wide sewer system design. Very different skillsets.
posted by damn dirty ape at 5:03 PM on January 29, 2008
Start small. Develop a lot of patience and realize that systems and programming are two very, very different skills. This is like a plumber complaining on the dififculty of municipal wide sewer system design. Very different skillsets.
posted by damn dirty ape at 5:03 PM on January 29, 2008
Coders are very bad teachers
This is absolutely true. This is an over-generalization, but I sometimes feel like there's a spectrum, with being good with people at one end, and people being good with programming at the other. The people who have lots of knowledge regarding programming are often really, really bad at conveying their knowledge.
Furthermore, there's a definite tendency for programmers to humor themselves by writing "obfuscated" code.
Not too long ago, I actually went to look over a bit of code I wrote about six months ago, trying to tweak something-or-other. I was looking through it, and thinking, "What the hell was this guy thinking?!" It's not that hard to write code, with ample experience. It is very hard to read code, though.
I'd like to add that Perl and UNIX shell scripting are two of the most arcane, unreadable languages I've ever worked in. Perl introduces some strange concepts that don't really translate into any other language, and that also make for really unreadable code. And I've cracked up laughing looking at UNIX scripts, convinced that someone actually banged on the keyboard. They're very "dense" scripts--you end up with one short line that does something incredibly complex.
In my experience, UNIX people also tend to take pride in the levels of obfuscation and downright obscurity of their code.
What's helpful to remember with shell scripting is that it's just a bunch of simple commands chained together. Are you familiar with the UNIX command line? Pipes? It's taken me years (but I never made an effort to learn anything special) before I'm at the point where I'm writing complex commands with sed and awk. A good place to start is to simply play around on the Linux command line, and get a feel for pipes and their power: "ls -l | grep ^d" will list directories, because it runs ls -l (list files, in long format), and then passes that output to grep, where you search for lines starting with (^) "d,' which is how it denotes directories. You just start adding increasingly obscure commands into the stream, and using increasingly obscure redirectors ("2>&1" is not intuitive or readable, no matter what people tell you).
posted by fogster at 5:10 PM on January 29, 2008 [1 favorite]
This is absolutely true. This is an over-generalization, but I sometimes feel like there's a spectrum, with being good with people at one end, and people being good with programming at the other. The people who have lots of knowledge regarding programming are often really, really bad at conveying their knowledge.
Furthermore, there's a definite tendency for programmers to humor themselves by writing "obfuscated" code.
Not too long ago, I actually went to look over a bit of code I wrote about six months ago, trying to tweak something-or-other. I was looking through it, and thinking, "What the hell was this guy thinking?!" It's not that hard to write code, with ample experience. It is very hard to read code, though.
I'd like to add that Perl and UNIX shell scripting are two of the most arcane, unreadable languages I've ever worked in. Perl introduces some strange concepts that don't really translate into any other language, and that also make for really unreadable code. And I've cracked up laughing looking at UNIX scripts, convinced that someone actually banged on the keyboard. They're very "dense" scripts--you end up with one short line that does something incredibly complex.
In my experience, UNIX people also tend to take pride in the levels of obfuscation and downright obscurity of their code.
What's helpful to remember with shell scripting is that it's just a bunch of simple commands chained together. Are you familiar with the UNIX command line? Pipes? It's taken me years (but I never made an effort to learn anything special) before I'm at the point where I'm writing complex commands with sed and awk. A good place to start is to simply play around on the Linux command line, and get a feel for pipes and their power: "ls -l | grep ^d" will list directories, because it runs ls -l (list files, in long format), and then passes that output to grep, where you search for lines starting with (^) "d,' which is how it denotes directories. You just start adding increasingly obscure commands into the stream, and using increasingly obscure redirectors ("2>&1" is not intuitive or readable, no matter what people tell you).
posted by fogster at 5:10 PM on January 29, 2008 [1 favorite]
I struggled at coding initially for a long time. I thought i can never be good at it.
But after lot of hardwork, i find it is the one of the simplest things to do.
This is what helped me...
1) I was lucky to work with few good engineers. I saw how they solved
the problems/wrote code. I followed it.
2) When i don't understand things, i discuss with friends who are kind
and who helpful.
My suggestion, try to find some good kind engineers and work on some group
projects with them.
Last but not the least , pl. find good engineers who are humble. If you get involved
with a person, who is proud, he might say coding is very difficult.
3) Also get your code reviewed by some one who is good. That way you get good
inputs. Also fix their code review comments. Take their comments with humble ness.
posted by tom123 at 5:11 PM on January 29, 2008
But after lot of hardwork, i find it is the one of the simplest things to do.
This is what helped me...
1) I was lucky to work with few good engineers. I saw how they solved
the problems/wrote code. I followed it.
2) When i don't understand things, i discuss with friends who are kind
and who helpful.
My suggestion, try to find some good kind engineers and work on some group
projects with them.
Last but not the least , pl. find good engineers who are humble. If you get involved
with a person, who is proud, he might say coding is very difficult.
3) Also get your code reviewed by some one who is good. That way you get good
inputs. Also fix their code review comments. Take their comments with humble ness.
posted by tom123 at 5:11 PM on January 29, 2008
Code can be particularly difficult to follow because it is sort of like a dump from the author's brain. Following a script is like following a mathematical derivation in a textbook. Sometimes they skip steps or do little shortcuts and unless you work the whole thing out by hand as you go it can be baffling. (Perl in particular is awful for understanding. The language is filled with shortcuts.)
Coding is like a lot of pursuits in that there are layers of complexity that build on top of one another. If you don't have all the fundamentals, because, oh, maybe you don't have years of experience coding and a degree in computer science like some of these guys, you might have no chance of understanding their code. You need to learn the tools first - basics like variables and control flow, followed by more advanced topics like data structures and algorithms.
On preview:
One of the difficulties you are sure to run into is that "why" is a tough question to answer. It depends on the language you want to use, there may be historical reasons for the way the language is put together, and often the root of the matter goes down to the hardware level. Educators long figured out that it is more effective to teach the abstract concepts - the tools I mentioned above, which can be implemented in any language - and let the student learn how to apply them in whichever language they're using. I wish I knew of good practical resources to point you to but I don't. I think you are going to have to try to have a little faith that programs work the way they do for a reason and put the question out of your mind why you learn the fundamentals. Once you are less befuddled by procedures and modules, you can start to dig in a bit more. Bite off manageable chunks or you risk being overwhelmed.
posted by PercussivePaul at 5:14 PM on January 29, 2008
Coding is like a lot of pursuits in that there are layers of complexity that build on top of one another. If you don't have all the fundamentals, because, oh, maybe you don't have years of experience coding and a degree in computer science like some of these guys, you might have no chance of understanding their code. You need to learn the tools first - basics like variables and control flow, followed by more advanced topics like data structures and algorithms.
On preview:
One of the difficulties you are sure to run into is that "why" is a tough question to answer. It depends on the language you want to use, there may be historical reasons for the way the language is put together, and often the root of the matter goes down to the hardware level. Educators long figured out that it is more effective to teach the abstract concepts - the tools I mentioned above, which can be implemented in any language - and let the student learn how to apply them in whichever language they're using. I wish I knew of good practical resources to point you to but I don't. I think you are going to have to try to have a little faith that programs work the way they do for a reason and put the question out of your mind why you learn the fundamentals. Once you are less befuddled by procedures and modules, you can start to dig in a bit more. Bite off manageable chunks or you risk being overwhelmed.
posted by PercussivePaul at 5:14 PM on January 29, 2008
Oh yeah, totally... tom123. Dude, you can learn how to program if you want...
For me, the key was just finding bite-sized projects to work on -- once I had a problem to solve, I was able to kind of work backwards and figure out how to do it by breaking it down into its component parts.
For example -- build a blog. You need to do the following:
1) Figure out to connect to databases
2) Design a really simple db structure that'll meet your needs
3) Put data into the db
4) Pull data out of a db in some specified order
5) Make it look like something, preferably something attractive
Anyway, you get the idea. The key is that it gets easier as you go, mostly in terms of just learning where you can go to research and solve problems.
posted by ph00dz at 5:19 PM on January 29, 2008 [1 favorite]
For me, the key was just finding bite-sized projects to work on -- once I had a problem to solve, I was able to kind of work backwards and figure out how to do it by breaking it down into its component parts.
For example -- build a blog. You need to do the following:
1) Figure out to connect to databases
2) Design a really simple db structure that'll meet your needs
3) Put data into the db
4) Pull data out of a db in some specified order
5) Make it look like something, preferably something attractive
Anyway, you get the idea. The key is that it gets easier as you go, mostly in terms of just learning where you can go to research and solve problems.
posted by ph00dz at 5:19 PM on January 29, 2008 [1 favorite]
I'm an very experienced programmer and PERL gives me a headache. And every time I've finished something in PERL, I feel vaguely dirty.
The way I'm going to answer your question is from a story I overheard about a comics convention. Some poor fanboy asked a prominent author how to get into comics. The author said, "get a really big stack of paper and a pile of pencils and start drawing."
That's what it takes. If you can find something compelling to push you forward, by all means leverage that. Start with anything that gives to big win feedback. I started by typing in BASIC programs published by David H. Ahl in Creative Computing. They sucked, but by typing them in and fixing typos, I learned what made them go and by tweaking them, I learned how to affect how them ran. So write stupid little things that write form letters or Mad Libs and type in names like Dixie Normous or Rich Bastard and giggle like an idiot at the output. Those jokes never get old.
When you get frustrated (we all do), just remember that your computer is stooPiD and that it can really only do the following things:
1. Move the contents of memory from one place to another
2. Perform simulated arithmetic/logic on fake numbers
3. Move either conditionally or unconditionally from one part of a program to another
4. Manipulate peripheral devices
That's it. Pretty stooPiD, huh?
posted by plinth at 5:20 PM on January 29, 2008
The way I'm going to answer your question is from a story I overheard about a comics convention. Some poor fanboy asked a prominent author how to get into comics. The author said, "get a really big stack of paper and a pile of pencils and start drawing."
That's what it takes. If you can find something compelling to push you forward, by all means leverage that. Start with anything that gives to big win feedback. I started by typing in BASIC programs published by David H. Ahl in Creative Computing. They sucked, but by typing them in and fixing typos, I learned what made them go and by tweaking them, I learned how to affect how them ran. So write stupid little things that write form letters or Mad Libs and type in names like Dixie Normous or Rich Bastard and giggle like an idiot at the output. Those jokes never get old.
When you get frustrated (we all do), just remember that your computer is stooPiD and that it can really only do the following things:
1. Move the contents of memory from one place to another
2. Perform simulated arithmetic/logic on fake numbers
3. Move either conditionally or unconditionally from one part of a program to another
4. Manipulate peripheral devices
That's it. Pretty stooPiD, huh?
posted by plinth at 5:20 PM on January 29, 2008
(its also very intimidating to me that other people are able to (seemingly) just walk right over and pick up a book and learn code in a weekend.
Given the context, I'd jokingly fault you for the missing close-parenthesis, but I have mismatched quotes above. ;)
Most programming languages are very similar. The people who "learn" a language over the weekend are probably just brushing up on the differences between a given language and what they're used to. Learning to program on a professional level takes years.
For example, yesterday I found myself trying to convert, in PHP, the contents of a variable into all lowercase. uc("String") and ucase("String") both failed. So I went to the PHP site (php.net), and saw that they call their function strtolower("String"). This is a mundane example, but it illustrates my point: at a certain point, all you're "learning" about a language is what it calls the functions you're trying to use.
posted by fogster at 5:30 PM on January 29, 2008
Given the context, I'd jokingly fault you for the missing close-parenthesis, but I have mismatched quotes above. ;)
Most programming languages are very similar. The people who "learn" a language over the weekend are probably just brushing up on the differences between a given language and what they're used to. Learning to program on a professional level takes years.
For example, yesterday I found myself trying to convert, in PHP, the contents of a variable into all lowercase. uc("String") and ucase("String") both failed. So I went to the PHP site (php.net), and saw that they call their function strtolower("String"). This is a mundane example, but it illustrates my point: at a certain point, all you're "learning" about a language is what it calls the functions you're trying to use.
posted by fogster at 5:30 PM on January 29, 2008
Response by poster: damn dirty ape:
"This sounds like a classic issue of someone unwilling to go through the painful process of learning and expecting to 'just figure it out.'"
No, not at all. In fact I'm very passionate about learning. (and a hard worker, I currently have 4 jobs) I'll sit for hours troubleshooting computer hardware problems and isolating system processes and threads to pinpoint virus/spyware/rootkit infections. I'll spend days taking a single computer and loading windows, reformatting and loading various Linux flavors, reformatting and doing other things with the box.
For systems troubleshooting, it seems easy because there are lots of step-by-step instructions that (at each step) explain why you are doing that step and how the results of that step are going to come in handy down the road. For code-writing, I havent (yet) found a book structured like that.
I'm glad to see so far though that a lot of my feelings are not uncommon. (that it DOES give other people headaches and code writers ARE bad teachers.)
posted by jmnugent at 5:30 PM on January 29, 2008
"This sounds like a classic issue of someone unwilling to go through the painful process of learning and expecting to 'just figure it out.'"
No, not at all. In fact I'm very passionate about learning. (and a hard worker, I currently have 4 jobs) I'll sit for hours troubleshooting computer hardware problems and isolating system processes and threads to pinpoint virus/spyware/rootkit infections. I'll spend days taking a single computer and loading windows, reformatting and loading various Linux flavors, reformatting and doing other things with the box.
For systems troubleshooting, it seems easy because there are lots of step-by-step instructions that (at each step) explain why you are doing that step and how the results of that step are going to come in handy down the road. For code-writing, I havent (yet) found a book structured like that.
I'm glad to see so far though that a lot of my feelings are not uncommon. (that it DOES give other people headaches and code writers ARE bad teachers.)
posted by jmnugent at 5:30 PM on January 29, 2008
While there are far more "disciplined" languages suited for large-scale programming projects, scripting languages such as perl, php, python, and ruby may be the easiest first language to pick up.
Many scripting languages have (1) relatively little formalism and syntactic cruft and (2) are not "hard-line" in terms of enforcing a particular computer science ideology. This means that there's relatively little extra "stuff" to remember, and you can delay the learning of various ideologies (dynamic types are bad, or static typing is bad, or everything is a function, or everything is an object, or everything is a string, etc.) and the various intellectual contortions that people who stick to a single ideology have to go through in order to accomplish useful work.
Especially after reading your reply to chrismear, I think the problem is that you're trying to learn both the specifics of a programming language, and general programming concepts, at the same time.
What you want to be doing, is to really first just learn programming as "I give computer list of instructions, it does them in order." Once you've got that down, then you can embrace the various computer science concepts that many languages offer.
posted by NucleophilicAttack at 5:32 PM on January 29, 2008
Many scripting languages have (1) relatively little formalism and syntactic cruft and (2) are not "hard-line" in terms of enforcing a particular computer science ideology. This means that there's relatively little extra "stuff" to remember, and you can delay the learning of various ideologies (dynamic types are bad, or static typing is bad, or everything is a function, or everything is an object, or everything is a string, etc.) and the various intellectual contortions that people who stick to a single ideology have to go through in order to accomplish useful work.
Especially after reading your reply to chrismear, I think the problem is that you're trying to learn both the specifics of a programming language, and general programming concepts, at the same time.
What you want to be doing, is to really first just learn programming as "I give computer list of instructions, it does them in order." Once you've got that down, then you can embrace the various computer science concepts that many languages offer.
posted by NucleophilicAttack at 5:32 PM on January 29, 2008
jmnugent, a friend asked me to begin teaching their ten year old programming. I thought long and hard about where to begin. I came up with the idea of beginning with Javascript, and it's been really good.
Reasons:
1. The results are immediate, we can write a quick funtion and see it all happen in the browser
2. Its ECMA, so it looks like a lot of other programming languages, Java, C#, C etc
3. We don't need to buy anything, all happens in the browser
4. There are a gazillion articles/howtos etc on the googles for your edification
5. it's a really nicely constucted language and a good intro into OO
6. It's fun
7. They are paying me
posted by mattoxic at 5:47 PM on January 29, 2008 [4 favorites]
Reasons:
1. The results are immediate, we can write a quick funtion and see it all happen in the browser
2. Its ECMA, so it looks like a lot of other programming languages, Java, C#, C etc
3. We don't need to buy anything, all happens in the browser
4. There are a gazillion articles/howtos etc on the googles for your edification
5. it's a really nicely constucted language and a good intro into OO
6. It's fun
7. They are paying me
posted by mattoxic at 5:47 PM on January 29, 2008 [4 favorites]
It sounds to me like you might be being confused by the fact that some books that are intended for experienced programmers actually start off with a very easy "Hello World" example in order to demonstrate the organization of project files, compiler invocation etc., before going straight into relatively advanced material.
Have a look at the table of contents for Learning Perl (click on items to get a sample of the text in that section). This is the kind of pace that you need. If you're trying to learn from the same books as your more experienced colleagues, you're probably going to be frustrated.
FWIW I don't see anything wrong with getting into Perl as a first language, it's easy to get a small program with a simple linear structure to do a lot of work thanks to the great libraries, and it's already being used extensively in your company.
posted by teleskiving at 5:48 PM on January 29, 2008
Have a look at the table of contents for Learning Perl (click on items to get a sample of the text in that section). This is the kind of pace that you need. If you're trying to learn from the same books as your more experienced colleagues, you're probably going to be frustrated.
FWIW I don't see anything wrong with getting into Perl as a first language, it's easy to get a small program with a simple linear structure to do a lot of work thanks to the great libraries, and it's already being used extensively in your company.
posted by teleskiving at 5:48 PM on January 29, 2008
There is a lot of overlap between bad teachers and code writers, but the problem is not as comprehensive as some people like to pretend.
I would like to reiterate what a lot of other people have said: reading production code is a bad way to learn basic coding ideas. Heck, reading code at all is a bad way to learn basic coding ideas. If ever there was a place to learn by doing, coding is it.
That said, I'm having a hard time tracking down a tutorial that steps through small building blocks. The Intro To Programming class I took oh so many years ago did take exactly that approach though, and it worked out very well.
From your comments it sounds like you would be best off taking a class in this -- something where someone would give you small projects to complete and help you get past the roadblocks in completing them.
posted by tkolar at 5:51 PM on January 29, 2008
I would like to reiterate what a lot of other people have said: reading production code is a bad way to learn basic coding ideas. Heck, reading code at all is a bad way to learn basic coding ideas. If ever there was a place to learn by doing, coding is it.
That said, I'm having a hard time tracking down a tutorial that steps through small building blocks. The Intro To Programming class I took oh so many years ago did take exactly that approach though, and it worked out very well.
From your comments it sounds like you would be best off taking a class in this -- something where someone would give you small projects to complete and help you get past the roadblocks in completing them.
posted by tkolar at 5:51 PM on January 29, 2008
No, not at all. In fact I'm very passionate about learning. (and a hard worker, I currently have 4 jobs) I'll sit for hours troubleshooting computer hardware problems and isolating system processes and threads to pinpoint virus/spyware/rootkit infections.
Err, none of the things you listed have anything to do with coding. None. Its not like you spent the last three weekends writing a database driven website by scratch. I think you need to realize that "I know computers" does not translate into "I know programming." At best, IT people on your level (and mine too) work with and and work around the code of others. I'm just humble enough to understand that this shit is hard and I dont trivialize it as something I can learn in a weekend and then when I dont blame coders for 'being bad teachers.' I'm just proud of my simple scripts that get the job done at work. Anything more complex than batch scripting or AutoIT scripting is beyond my skills and I understand those with those skills spent many years developing them.
Like I wrote above, its a long road and expecting to sidestep it is exactly why youre in the predicament youre in right now. I'm not trying to be an argumentative asshole but your assumptions here are just plain wrong. This will take you a year or two of practice to catch up a beginer perl hacker. I'd avoid perl altogether if I was you.
posted by damn dirty ape at 5:51 PM on January 29, 2008
Err, none of the things you listed have anything to do with coding. None. Its not like you spent the last three weekends writing a database driven website by scratch. I think you need to realize that "I know computers" does not translate into "I know programming." At best, IT people on your level (and mine too) work with and and work around the code of others. I'm just humble enough to understand that this shit is hard and I dont trivialize it as something I can learn in a weekend and then when I dont blame coders for 'being bad teachers.' I'm just proud of my simple scripts that get the job done at work. Anything more complex than batch scripting or AutoIT scripting is beyond my skills and I understand those with those skills spent many years developing them.
Like I wrote above, its a long road and expecting to sidestep it is exactly why youre in the predicament youre in right now. I'm not trying to be an argumentative asshole but your assumptions here are just plain wrong. This will take you a year or two of practice to catch up a beginer perl hacker. I'd avoid perl altogether if I was you.
posted by damn dirty ape at 5:51 PM on January 29, 2008
damn dirty ape wrote...
Actually, the first thing he mentions is absolutely vital to coding. The ability to sit for hours troubleshooting is an extremely important skill to have. As a professional coder I spend far more time trying to figure out things that are broken than I do creating new stuff from scratch.
posted by tkolar at 5:56 PM on January 29, 2008
I'll sit for hours troubleshooting computer hardware problems and isolating system processes and threads to pinpoint virus/spyware/rootkit infections.Err, none of the things you listed have anything to do with coding. None.
Actually, the first thing he mentions is absolutely vital to coding. The ability to sit for hours troubleshooting is an extremely important skill to have. As a professional coder I spend far more time trying to figure out things that are broken than I do creating new stuff from scratch.
posted by tkolar at 5:56 PM on January 29, 2008
like teleskiving, I also don't see a problem with perl as the first language. (It was what I learned.) On the other hand, Dijkstra's warning about BASIC does come to mind!
Perl has many idiosyncracies, and by the time you get to the arcane reference and dereference syntax and the bolted on OOP, it's really not worth it anymore. By then certain parts of perl will feel tedious and kludgy enough for you to appreciate more refined tools like Forth, OCaml, or SmallTalk.
The basic perl syntax, on the other hand, is C-ish, the sigils are great for a new programmer, and the dynamic typing kills off a whole class of otherwise inscrutable compiler errors. At the beginning, perl's fine for learning things like assignments, loops, conditionals, and of course the industry standard perl5 regexps.
posted by NucleophilicAttack at 5:57 PM on January 29, 2008
Perl has many idiosyncracies, and by the time you get to the arcane reference and dereference syntax and the bolted on OOP, it's really not worth it anymore. By then certain parts of perl will feel tedious and kludgy enough for you to appreciate more refined tools like Forth, OCaml, or SmallTalk.
The basic perl syntax, on the other hand, is C-ish, the sigils are great for a new programmer, and the dynamic typing kills off a whole class of otherwise inscrutable compiler errors. At the beginning, perl's fine for learning things like assignments, loops, conditionals, and of course the industry standard perl5 regexps.
posted by NucleophilicAttack at 5:57 PM on January 29, 2008
Examples like this are what keep me wondering if I'm doomed to be forever a visual person.
I think the lack of visual thinkers is why people can't explain programming, and why there is so much crap software out there. They don't know how it works either.
jmnugent, programming and "figuring stuff out" are two totally different skills. Programming is writing a novel, problem solving is putting the pages of a book back in order. One informs the other, but they are different.
All the advice here is good. (Except the bit about just making random changes to code to see what happens. That's an insane way to learn anything.)
Seek to understand computers and operating systems as deeply as you can stand, or you will forever be stuck throwing stuff against a wall to see what sticks.
Programming languages are like human languages- they don't translate in a direct sort of way. Some languages have one word for a ten-word concept in some other language.
And don't discount that computer people are, as a class, extremely territorial. Don't discount that people who are unable to explain something to you are merely unwilling to.
Oh, and read this: if you understand it, you will understand more than 90% of IT people out there.
http://www.faqs.org/docs/artu/index.html
posted by gjc at 6:09 PM on January 29, 2008
I think the lack of visual thinkers is why people can't explain programming, and why there is so much crap software out there. They don't know how it works either.
jmnugent, programming and "figuring stuff out" are two totally different skills. Programming is writing a novel, problem solving is putting the pages of a book back in order. One informs the other, but they are different.
All the advice here is good. (Except the bit about just making random changes to code to see what happens. That's an insane way to learn anything.)
Seek to understand computers and operating systems as deeply as you can stand, or you will forever be stuck throwing stuff against a wall to see what sticks.
Programming languages are like human languages- they don't translate in a direct sort of way. Some languages have one word for a ten-word concept in some other language.
And don't discount that computer people are, as a class, extremely territorial. Don't discount that people who are unable to explain something to you are merely unwilling to.
Oh, and read this: if you understand it, you will understand more than 90% of IT people out there.
http://www.faqs.org/docs/artu/index.html
posted by gjc at 6:09 PM on January 29, 2008
Oh, one last thing on coding -- professional level coding requires you to teach yourself new things every week. Even if you stick with a single language, the libraries and operating systems shift underneath you *constantly*. And then of course there are the problems that you create for yourself that you can only find and fix by inventing a new way to debug your own software.
Making code purposefully obscure isn't tolerated in professional circles, but frankly a lot of code ends up obscure by default. It's hard work figuring all this crap out, and unless it's something that you truly truly love doing you probably won't find that it's worth your time to learn.
posted by tkolar at 6:12 PM on January 29, 2008
Making code purposefully obscure isn't tolerated in professional circles, but frankly a lot of code ends up obscure by default. It's hard work figuring all this crap out, and unless it's something that you truly truly love doing you probably won't find that it's worth your time to learn.
posted by tkolar at 6:12 PM on January 29, 2008
And the reason to formally study languages is so that you don't become this guy:
As a professional coder I spend far more time trying to figure out things that are broken than I do creating new stuff from scratch.
Formal learning prevents this sort of "hey, I think I'll use this function to see what it does. screw reading the manual." Real pros spend hours finding typos, not their own programming errors.
posted by gjc at 6:15 PM on January 29, 2008
As a professional coder I spend far more time trying to figure out things that are broken than I do creating new stuff from scratch.
Formal learning prevents this sort of "hey, I think I'll use this function to see what it does. screw reading the manual." Real pros spend hours finding typos, not their own programming errors.
posted by gjc at 6:15 PM on January 29, 2008
NucleophilicAttack brings up a good point:
I think the problem is that you're trying to learn both the specifics of a programming language, and general programming concepts, at the same time.
Those people who teach themselves a programming language in a weekend, they can do it because they've got the general programming concepts down, so all they need to learn is the syntax of the new language.
That said, take a look at this book: How to Think Like a Computer Scientist: Learning with Python. Jeffrey Elkner originally started working on it to teach high school students to program. So no prior knowledge of computing concepts or programming languages is assumed.
posted by needled at 6:32 PM on January 29, 2008 [1 favorite]
I think the problem is that you're trying to learn both the specifics of a programming language, and general programming concepts, at the same time.
Those people who teach themselves a programming language in a weekend, they can do it because they've got the general programming concepts down, so all they need to learn is the syntax of the new language.
That said, take a look at this book: How to Think Like a Computer Scientist: Learning with Python. Jeffrey Elkner originally started working on it to teach high school students to program. So no prior knowledge of computing concepts or programming languages is assumed.
posted by needled at 6:32 PM on January 29, 2008 [1 favorite]
Response by poster:
I'm not trying to be argumentative either,.. I'm just trying to come to a new understanding. (people often think I'm being "thick" and "difficult"... thats not my intent, I just want to learn. :| )
Damn dirty ape:
"I think you need to realize that "I know computers" does not translate into "I know programming."
It would seem to me that they should translate... I mean, code runs on computers, right? Its not like I'm a world renowned ballerina trying to switch careers to be a rocket scientist.
At best, IT people on your level (and mine too) work with and and work around the code of others. I'm just humble enough to understand that this shit is hard and I don't trivialize it as something I can learn in a weekend and then when I dont blame coders for 'being bad teachers.'
I dont expect to learn it over a weekend. First I want to understand if the difficulty I am feeling is based in mistakes in my approach to learning, OR ... because the nature of learning programming is inherently difficult (which it sounds like it is)
Next I would want to go out and find all the useful learning resources (thanks Odinsdream and (apparently) figure it out for myself. And hopefully not become another "bad coder" in the process.
posted by jmnugent at 6:42 PM on January 29, 2008
I'm not trying to be argumentative either,.. I'm just trying to come to a new understanding. (people often think I'm being "thick" and "difficult"... thats not my intent, I just want to learn. :| )
Damn dirty ape:
"I think you need to realize that "I know computers" does not translate into "I know programming."
It would seem to me that they should translate... I mean, code runs on computers, right? Its not like I'm a world renowned ballerina trying to switch careers to be a rocket scientist.
At best, IT people on your level (and mine too) work with and and work around the code of others. I'm just humble enough to understand that this shit is hard and I don't trivialize it as something I can learn in a weekend and then when I dont blame coders for 'being bad teachers.'
I dont expect to learn it over a weekend. First I want to understand if the difficulty I am feeling is based in mistakes in my approach to learning, OR ... because the nature of learning programming is inherently difficult (which it sounds like it is)
Next I would want to go out and find all the useful learning resources (thanks Odinsdream and (apparently) figure it out for myself. And hopefully not become another "bad coder" in the process.
posted by jmnugent at 6:42 PM on January 29, 2008
Nthing what everyone else has said:
1) Reading real-world production code is way too rough of an intro into programming. Even if it's well written, it's likely to be too big, too complex and too reliant on various libraries beyond the basic language which you might have a reference for. It's also very likely that you might be trying to make sense out of convoluted spaghetti code which just "grew" that way for various historical reasons.
2) There are books like what you describe, presenting progressively more difficult examples. However you have to search for them, because most of the books on the market are aimed at readers who already have some background. When I was first learning to program, I had a really good time with John Smiley's various "learn to program" titles. However most of his books are probably pretty dated by now. I also remember Dave Thau's Book of Javascript as being pretty good for a beginner.
3) I agree with the suggestions to start with a scripting language. Javascript is pretty cool for a beginner because all you need is a text editor and a browser.
4) If you're interested in the underlying "WHY" of how programming works, then I second the recommendation of Code by Charles Petzold. However don't get too caught up at first in the "WHY" of the details of the implementation for a programming language when you first start out.
5) You really do have to spend a lot of time writing code and trying it out as well as reading code before you start to really intuitively grok it.
6) There are coders out there who know how to teach, but you can't count on a randomly selected programmer to have the inclination and the communication skills to help you out. I enjoy explaining basic programming concepts, but I'm probably in a minority.
posted by tdismukes at 6:46 PM on January 29, 2008
1) Reading real-world production code is way too rough of an intro into programming. Even if it's well written, it's likely to be too big, too complex and too reliant on various libraries beyond the basic language which you might have a reference for. It's also very likely that you might be trying to make sense out of convoluted spaghetti code which just "grew" that way for various historical reasons.
2) There are books like what you describe, presenting progressively more difficult examples. However you have to search for them, because most of the books on the market are aimed at readers who already have some background. When I was first learning to program, I had a really good time with John Smiley's various "learn to program" titles. However most of his books are probably pretty dated by now. I also remember Dave Thau's Book of Javascript as being pretty good for a beginner.
3) I agree with the suggestions to start with a scripting language. Javascript is pretty cool for a beginner because all you need is a text editor and a browser.
4) If you're interested in the underlying "WHY" of how programming works, then I second the recommendation of Code by Charles Petzold. However don't get too caught up at first in the "WHY" of the details of the implementation for a programming language when you first start out.
5) You really do have to spend a lot of time writing code and trying it out as well as reading code before you start to really intuitively grok it.
6) There are coders out there who know how to teach, but you can't count on a randomly selected programmer to have the inclination and the communication skills to help you out. I enjoy explaining basic programming concepts, but I'm probably in a minority.
posted by tdismukes at 6:46 PM on January 29, 2008
"I think you need to realize that "I know computers" does not translate into "I know programming."
It would seem to me that they should translate... I mean, code runs on computers, right? Its not like I'm a world renowned ballerina trying to switch careers to be a rocket scientist.
"I can drive a car" doesn't mean "I can build an internal combustion engine".
Thats not to say that you can't learn to code though, it's just that both tasks use very different skill sets.
Take a language like python, look at the resources linked in this thread, particularly the ones needled linked above, and just dive in and do it. It's not going to happen overnight, which you seem comfortable with, but it will pick up the basic concepts pretty quickly and can build from there.
posted by jjb at 7:09 PM on January 29, 2008
It would seem to me that they should translate... I mean, code runs on computers, right? Its not like I'm a world renowned ballerina trying to switch careers to be a rocket scientist.
"I can drive a car" doesn't mean "I can build an internal combustion engine".
Thats not to say that you can't learn to code though, it's just that both tasks use very different skill sets.
Take a language like python, look at the resources linked in this thread, particularly the ones needled linked above, and just dive in and do it. It's not going to happen overnight, which you seem comfortable with, but it will pick up the basic concepts pretty quickly and can build from there.
posted by jjb at 7:09 PM on January 29, 2008
And the reason to formally study languages is so that you don't become this guy:
As a professional coder I spend far more time trying to figure out things that are broken than I do creating new stuff from scratch.
Formal learning prevents this sort of "hey, I think I'll use this function to see what it does. screw reading the manual." Real pros spend hours finding typos, not their own programming errors.
What? Formal learning does not prevent writing bugs, and most of the bugs I see in complex code are not related to reading the manual. Frankly, if you're spending hours finding typos more than once or twice a year, you are using the wrong language or coding style.
To the OP, look dude, you might just need to take a class. There's a chance that the instructor won't be that great, but having a person take you through the basics step by step is probably what you need. I am a damned good programmer these days, but I needed the structure of the classroom to get the basics drilled into my head. Those problem-solving skills will absolutely come to great use when you are an experienced programmer (finding other people's bugs, if not your own) but they aren't enough to teach you the basics. And I know plenty of visual learners (isn't the "male" stereotype visual learner?) who code quite well. Of course, scripts tend to give me headaches as well and I would not recommend anyone learn to code on Perl.
posted by ch1x0r at 7:16 PM on January 29, 2008
What strikes me as odd is that you're looking to tutorials/books/whatever to give you your projects and your reasons for why to do things a certain way. At the beginning level, this should really come from you. You should be coming up with a project or task - then figuring out how to make it happen is pretty much just figuring out the individual steps that make it happen. For example: lets say your project is that you want to print out all the numbers from 1 to 100.
Step 1. I need to know how to print something. "echo $variable"
Step 2. Well how do i change what $ variable is? "$variable =1"
Step 3. Well now how do I increment a variable? "$variable++"
Step 4. How do I repeat that until i've printed all of the numbers from 1-100? "while($variable <>
Step 5. Put it all together
You should try coming up with simple tasks that you know could be automated by coding, then make yourself a flowchart of every little step to get it done, From there it's pretty much just picking a language and matching up the keywords to what your flowchart says.
posted by JRGould at 7:17 PM on January 29, 2008
Step 1. I need to know how to print something. "echo $variable"
Step 2. Well how do i change what $ variable is? "$variable =1"
Step 3. Well now how do I increment a variable? "$variable++"
Step 4. How do I repeat that until i've printed all of the numbers from 1-100? "while($variable <>
Step 5. Put it all together
$variable=1;That's the thing about coding, from my standpoint at least, you control the 'why do you do it like that?' beyond that it's like asking 'why is the word enough spelled the way it is?' it's language, it's syntax, a means to an end. (unless you want to know the real binary-level why/how in which case... a comp-sci degree would be a start)
while($variable<> echo $variable;
$variable++;
}
You should try coming up with simple tasks that you know could be automated by coding, then make yourself a flowchart of every little step to get it done, From there it's pretty much just picking a language and matching up the keywords to what your flowchart says.
posted by JRGould at 7:17 PM on January 29, 2008
Ok I really can't improve on the advice that people have given above but I'll offer a practical suggestion that really helped me personally. Last semester I took a course at Cornell called Computational Methods for Nonlinear Systems. Don't get scared by the title of this course. It is meant to be an interactive lab based course with self contained modules to implement various cool things in physics and biology using Python. The best thing about this course is the approach which I've never seen used before. Each module had a short document describing the methods used in the code and background information and a skeletal code file with detailed instructions on what code to write in each function. It is very self contained with a concise but precise instructions including the why of different components of code. I found the course invaluable for helping clarify what's so great about object oriented programming and for getting tangible results quickly. Really really helped my programming skills immensely. I've probably done a terrible job of describing this but just click on the link and see for yourself. The guys who teach this course are great believers in Open Source so the course material is up there for anyone to use. I highly recommend the site.
posted by peacheater at 7:19 PM on January 29, 2008 [1 favorite]
posted by peacheater at 7:19 PM on January 29, 2008 [1 favorite]
guh html seemed to muss 'step 5'
should read:
should read:
$variable=1;posted by JRGould at 7:20 PM on January 29, 2008
while($variable<=100){
echo $variable;
$variable++;
}
I am the only code geek who is kinda sorta offended here? During the last 10 years, I've gone to school, got my B.Sc. in Computer Science, spent 8 years "coding" professionally. I've spent a lot of time and energy learning my craft and developing my skills, and generally becoming proficient at what I do. In conjunction with the good code I've written, i've also generated some rather large, steaming piles of code shit. But I do know the difference. And during the last 10 years, I've also become painfully aware of what skills and inherent "coding" brilliance I lack.
At the very least, however, I am one of those people who can "pick up a book and learn code" in a weekend. I'm doing that with Python, right now, actually. And to be honest, I don't even really need a weekend, just some good documentation and the interpreter pointing out my syntax errors. But to think that anybody who just "knows computers" would be able to do that, or expect to be able to do that, is well, a tad offensive, and demeans the effort I've put in the last 10 years.
Coding is a skill, like everything else. You need time to practice your skill, and to get good at it. And no, not everyone can do it. But then again, you won't know until you try.
Rome wasn't built it a day, and you can't figure out how it works just by looking at the finished product. Especially if it was built by rushed geeks who needed it to work yesterday and have managers and clients breathing down their necks.
posted by cgg at 7:33 PM on January 29, 2008 [3 favorites]
At the very least, however, I am one of those people who can "pick up a book and learn code" in a weekend. I'm doing that with Python, right now, actually. And to be honest, I don't even really need a weekend, just some good documentation and the interpreter pointing out my syntax errors. But to think that anybody who just "knows computers" would be able to do that, or expect to be able to do that, is well, a tad offensive, and demeans the effort I've put in the last 10 years.
Coding is a skill, like everything else. You need time to practice your skill, and to get good at it. And no, not everyone can do it. But then again, you won't know until you try.
Rome wasn't built it a day, and you can't figure out how it works just by looking at the finished product. Especially if it was built by rushed geeks who needed it to work yesterday and have managers and clients breathing down their necks.
posted by cgg at 7:33 PM on January 29, 2008 [3 favorites]
Please check your metafilter mail
posted by Calibandage at 7:41 PM on January 29, 2008
posted by Calibandage at 7:41 PM on January 29, 2008
because the nature of learning programming is inherently difficult (which it sounds like it is)
Also, I don't believe that this is the case. IMO, it's a matter of grasping the basics. The rest is syntax (...he said in overly cavalier fashion...).
posted by Calibandage at 7:50 PM on January 29, 2008 [1 favorite]
Also, I don't believe that this is the case. IMO, it's a matter of grasping the basics. The rest is syntax (...he said in overly cavalier fashion...).
posted by Calibandage at 7:50 PM on January 29, 2008 [1 favorite]
Learn to use a source-level debugger to step through the code and watch how it changes the data.
posted by Coventry at 8:12 PM on January 29, 2008
posted by Coventry at 8:12 PM on January 29, 2008
And the reason to formally study languages is so that you don't become this guy:
Heh.
Come back when you've worked on a few different systems with 1 million or more lines of code.
Languages are well documented, actual working legacy systems are not.
Oh, if life were so simple that knowing the language backwards and forwards were anything other than a starting point.
posted by tkolar at 8:19 PM on January 29, 2008 [1 favorite]
As a professional coder I spend far more time trying to figure out things that are broken than I do creating new stuff from scratch.Formal learning prevents this sort of "hey, I think I'll use this function to see what it does. screw reading the manual." Real pros spend hours finding typos, not their own programming errors.
Heh.
Come back when you've worked on a few different systems with 1 million or more lines of code.
Languages are well documented, actual working legacy systems are not.
Oh, if life were so simple that knowing the language backwards and forwards were anything other than a starting point.
posted by tkolar at 8:19 PM on January 29, 2008 [1 favorite]
Here are a few sites that might be useful to you in your quest to learn programming.
How to learn Programming In 10 years
How to Design Programs: An Introduction to Computing and Programming
Structure and Interpretation of Programs
Videos that accompany the book above(They are quite old but useful)
posted by yertledaturtle at 8:57 PM on January 29, 2008 [2 favorites]
How to learn Programming In 10 years
How to Design Programs: An Introduction to Computing and Programming
Structure and Interpretation of Programs
Videos that accompany the book above(They are quite old but useful)
posted by yertledaturtle at 8:57 PM on January 29, 2008 [2 favorites]
I'd try poking around with Ruby. It's very common-sense. Play with this Try Ruby! (in your browser) page with a live interpreter built-in to get an idea of how it's done. It's pretty nifty.
posted by loiseau at 9:35 PM on January 29, 2008 [1 favorite]
posted by loiseau at 9:35 PM on January 29, 2008 [1 favorite]
Late to the party, but I would recommend going through this tutorial that teaches you Ruby. If you read this and do end up going through this tutorial, please give me some feedback. I'm a professional coder who started on a TRS-80, so I don't have the perspective of a beginner. I usually recommend this to programming beginners, but would appreciate some feedback to see if it's as good as I think it is!
I feel this tutorial adequately addresses the major obstacles in beginning to understand programming -- data storage, the difference between a reference and a variable, functions, and object orientation. It forces you to type as you go through the tutorial, so you will overcome the mental hurdle of submitting code to a computer and you can begin to program instantly.
posted by sleslie at 10:25 PM on January 29, 2008 [1 favorite]
I feel this tutorial adequately addresses the major obstacles in beginning to understand programming -- data storage, the difference between a reference and a variable, functions, and object orientation. It forces you to type as you go through the tutorial, so you will overcome the mental hurdle of submitting code to a computer and you can begin to program instantly.
posted by sleslie at 10:25 PM on January 29, 2008 [1 favorite]
Don't try to start with anything web based. Web based always requires understanding 3 different concepts - databases, programming language and html. It's tough to start.
Start with console based C. It's straightforward.
posted by markovich at 3:37 AM on January 30, 2008
Start with console based C. It's straightforward.
posted by markovich at 3:37 AM on January 30, 2008
The one thing that many people have already touched on in this thread, is choosing an appropriate toy project or toy projects to work on while you learn programming.
I'm exaggerating here, but don't try to clone Quake as your very first project. Start simple. Math puzzles that require computers for a solution are often a good thing to try.
Exercises and projects that emphasize the fundamentals are key: data structures, program logic, algorithmic complexity, properly analyzing decomposing your problem into well-defined pieces, and so on.
Learning how to use GUI toolkits, how to do input/output, database bindings, web programming and talking to apache, all that will be for later.
posted by NucleophilicAttack at 7:00 AM on January 30, 2008
I'm exaggerating here, but don't try to clone Quake as your very first project. Start simple. Math puzzles that require computers for a solution are often a good thing to try.
Exercises and projects that emphasize the fundamentals are key: data structures, program logic, algorithmic complexity, properly analyzing decomposing your problem into well-defined pieces, and so on.
Learning how to use GUI toolkits, how to do input/output, database bindings, web programming and talking to apache, all that will be for later.
posted by NucleophilicAttack at 7:00 AM on January 30, 2008
For what it's worth...
I work in the web field and would consider myself primarily an artist/graphic designer. I failed horribly at math in school, and I still can't successfully figure out percentages on how much to tip someone. I love debit/credit cards just because I don't have to actually double check and make sure my change is right.
Yeah, I'm REALLY that bad at all that left brain stuff.
That said, I'm also a skilled PHP programmer. I can make javascript work, I've wrangled ASP from knowing nothing at all about it, and I can look at Perl without feeling like I'm reading greek.
For me, with a good understanding of HTML, the best way to jump into programming was to learn PHP. It's a lot easier than a "real" programming language (its considered a scripting language) because you don't need to mess with a lot of technical and obscure concepts like file pointers (which still throw me for a loop... like wth?) compilers and the like.
Whatever language you want to start with, think of something simple you actually want to build. Doesn't matter if it's been done before. Find tutorials or buy a book that shows you how to do it. Then follow the instructions and do it. There's immense satisfaction and motivation in being able to actually build useful utilities and applications, no matter how small they may be.
You have to realize that at first, you probably won't understand half of what you're actually doing, and that's OK. Doing comes first, then comes understanding. You just have to kind of accept that alot of it is gobbly-gook... the more you do (even if you're just following instructions in a tutorial) the more things will start to slowly make sense.
ie. "Hey, I remember doing this same thing in my last little script, doing it here has the same result! I guess this function does this."
Also, I'd highly advise staying away from ANYONE technical. Most technical people are HORRIBLE teachers (sorry guys, you're crazy smart, but you just don't know how to explain things to us poor non-techy people). It's really good to hook up with other beginners, they're learning too and will be able explain things better because they know what made the lightbulb click on in their head.
posted by finitejest at 7:28 AM on January 30, 2008
I work in the web field and would consider myself primarily an artist/graphic designer. I failed horribly at math in school, and I still can't successfully figure out percentages on how much to tip someone. I love debit/credit cards just because I don't have to actually double check and make sure my change is right.
Yeah, I'm REALLY that bad at all that left brain stuff.
That said, I'm also a skilled PHP programmer. I can make javascript work, I've wrangled ASP from knowing nothing at all about it, and I can look at Perl without feeling like I'm reading greek.
For me, with a good understanding of HTML, the best way to jump into programming was to learn PHP. It's a lot easier than a "real" programming language (its considered a scripting language) because you don't need to mess with a lot of technical and obscure concepts like file pointers (which still throw me for a loop... like wth?) compilers and the like.
Whatever language you want to start with, think of something simple you actually want to build. Doesn't matter if it's been done before. Find tutorials or buy a book that shows you how to do it. Then follow the instructions and do it. There's immense satisfaction and motivation in being able to actually build useful utilities and applications, no matter how small they may be.
You have to realize that at first, you probably won't understand half of what you're actually doing, and that's OK. Doing comes first, then comes understanding. You just have to kind of accept that alot of it is gobbly-gook... the more you do (even if you're just following instructions in a tutorial) the more things will start to slowly make sense.
ie. "Hey, I remember doing this same thing in my last little script, doing it here has the same result! I guess this function does this."
Also, I'd highly advise staying away from ANYONE technical. Most technical people are HORRIBLE teachers (sorry guys, you're crazy smart, but you just don't know how to explain things to us poor non-techy people). It's really good to hook up with other beginners, they're learning too and will be able explain things better because they know what made the lightbulb click on in their head.
posted by finitejest at 7:28 AM on January 30, 2008
I think it takes a certain kind of mentality to be involved with programming. If you have a problem with scripts and markup languages and config files, it sounds to me like this is not your thing (sorry!). And just because it happens on a computer does not mean that you should be good at it because you work with computers. I'm "good with computers" too, but my ability to open up a computer and do something beneficials starts and stops at putting in memory or a hard drive. I don't know how to build my own, I don't know how electrical circuits work, and when I picked up a book on very basic electronics to try to see if I could figure it out I found that I cannot. I handle abstract concepts like data structures very well, but struggle when dealing with more physical items, I guess.
Similarly, while I can understand that an operating system exists and knows the basics of what it does, I also know that it will probably always be beyond my skill level to try to understand the inner works of, say, the linux kernel, even if I were to teach myself C.
If you do want to start, ignore trying to learn a specific language and focus on the basics of understanding programming concepts. From a programming standpoint, putting functions into chapter 2 of an introductory book absolutely makes sense and so your frustration with that suggests you need to focus on the fundamentals of programming in general.
If you still want to go for it, choose a book that teaches to program, not a specfic language, and one that is easy to set up and use, and has a fast payoff (so, for example, a compiled language would probably be a bad choice, as well as one that required a lot of extra syntax, such as a language which required you to declare variables or perform a lot of extra legwork). Once you've started, give it a significant amount of time. Most people who "pick up" languages today spent a good deal of their childhoods or young adulthood struggling over one or two languages.
posted by Deathalicious at 11:30 AM on January 30, 2008
Similarly, while I can understand that an operating system exists and knows the basics of what it does, I also know that it will probably always be beyond my skill level to try to understand the inner works of, say, the linux kernel, even if I were to teach myself C.
If you do want to start, ignore trying to learn a specific language and focus on the basics of understanding programming concepts. From a programming standpoint, putting functions into chapter 2 of an introductory book absolutely makes sense and so your frustration with that suggests you need to focus on the fundamentals of programming in general.
If you still want to go for it, choose a book that teaches to program, not a specfic language, and one that is easy to set up and use, and has a fast payoff (so, for example, a compiled language would probably be a bad choice, as well as one that required a lot of extra syntax, such as a language which required you to declare variables or perform a lot of extra legwork). Once you've started, give it a significant amount of time. Most people who "pick up" languages today spent a good deal of their childhoods or young adulthood struggling over one or two languages.
posted by Deathalicious at 11:30 AM on January 30, 2008
From a programming standpoint, putting functions into chapter 2 of an introductory book absolutely makes sense
I almost said the same thing, but in thinking about it I realized that you can get a tremendous amount of mileage out of for-loops, while-loops, etc. I'm guessing that for the poster, functions belong in about chapter 4.
While functions are a vital part of any modern programming language, they're still much more of a convenience than a necessity to the act of programming itself.
posted by tkolar at 12:00 PM on January 30, 2008
I almost said the same thing, but in thinking about it I realized that you can get a tremendous amount of mileage out of for-loops, while-loops, etc. I'm guessing that for the poster, functions belong in about chapter 4.
While functions are a vital part of any modern programming language, they're still much more of a convenience than a necessity to the act of programming itself.
posted by tkolar at 12:00 PM on January 30, 2008
The placement of functions depends on the language at hand, I think. C is something like 8 commands plus an endless number of functions. Knowing about them from the start explains why you have to say
#include
to be able to do almost anything.
But in a BASIC program, functions are silly.
Functions are a necessity from a standpoint of programming hygiene. The whole point of modern programming is splitting everything out to a function so that the main procedure (pascal, anyone?) is clear and concise, with the nuts and bolts happening in the "black box" of the function. Or so I was taught.
posted by gjc at 6:47 PM on January 30, 2008
#include
to be able to do almost anything.
But in a BASIC program, functions are silly.
Functions are a necessity from a standpoint of programming hygiene. The whole point of modern programming is splitting everything out to a function so that the main procedure (pascal, anyone?) is clear and concise, with the nuts and bolts happening in the "black box" of the function. Or so I was taught.
posted by gjc at 6:47 PM on January 30, 2008
tkolar: "While functions are a vital part of any modern programming language, they're still much more of a convenience than a necessity to the act of programming itself."
Unless it's a functional programming language, in which case they are the language. And anyway, the writing a function is a) fundamental to most programming languages, even many procedural ones and b) pretty frikken easy compared to other programming tasks
posted by Deathalicious at 8:26 PM on January 30, 2008
Unless it's a functional programming language, in which case they are the language. And anyway, the writing a function is a) fundamental to most programming languages, even many procedural ones and b) pretty frikken easy compared to other programming tasks
posted by Deathalicious at 8:26 PM on January 30, 2008
Functions are a necessity from a standpoint of programming hygiene.
Oh, I totally agree. If you're going to write a program of any size they're absolutely necessary.
I was just thinking that for someone who is just learning there are any number of interesting programs that can be written in half a screen using only a few variables, a while loop and a bunch of if thens.
For example, a beginner could learn a tremendous amount about programming logic by being given an array with 10 numbers in it and having to print them out in order. And after they've learned to write and debug such a program, showing them how to move that code into a general purpose function becomes very topical.
I just think people should get their feet wet writing an actual algorithm before potentially getting bogged down in function syntax. Essentially, they should have something of their own to put *in* the function before they get introduced to them.
posted by tkolar at 8:49 PM on January 30, 2008
Oh, I totally agree. If you're going to write a program of any size they're absolutely necessary.
I was just thinking that for someone who is just learning there are any number of interesting programs that can be written in half a screen using only a few variables, a while loop and a bunch of if thens.
For example, a beginner could learn a tremendous amount about programming logic by being given an array with 10 numbers in it and having to print them out in order. And after they've learned to write and debug such a program, showing them how to move that code into a general purpose function becomes very topical.
I just think people should get their feet wet writing an actual algorithm before potentially getting bogged down in function syntax. Essentially, they should have something of their own to put *in* the function before they get introduced to them.
posted by tkolar at 8:49 PM on January 30, 2008
This thread is closed to new comments.
You said you managed to get some "hello world" stuff working. What's stopped you from progressing further down the road of self-learning using tutorials and the like?
posted by chrismear at 4:26 PM on January 29, 2008