Programming blind spot.

[Oleron]

I've been in IT in various roles for many years. I'm a decent sysadmin with a wide range of skills, I pick up new skills very quickly.

I like to think I'm pretty smart too. I have a degree and I believe that I have above-average intelligence and a great thirst for knowledge.

Except....

When it comes to programming. I am fascinated by computer programming and have read many books on the subject. I have studied programming self-teach books on several languages - notably Java, C++ and VB. When I read them, I think I understand them but when it comes to actually 'writing a program' I take a complete mental blank and have no idea where to start.

I'm beginning to think my brain is just not 'built' to program. I just can't retain or absorb the information I need. I never have that Eureka moment where it all suddenly becomes clear.

I don't really need to know how to program for my job, although scripting and manipulation of the Windows API would come in useful. It's the thought that I CAN'T program, no matter how hard I try, that bothers me. I see it as an intellectual challenge.

I know this board is brimming with development expertise so has anyone got any ideas that might help? Or is the best advice, "Give it up, you'll never be any good at it"?

[jmontecillo01]

I don't know if others would agree with this but this is based on my experience.

When I first started to learn programming (COBOL), my brother had an S/370 Assembly language book. Learning the most basic about computers had helped me a lot to learn the language. I was programming in 3 weeks time.

I suggest that you familiarize yourself with binary arithmetic and boolean arithmetic. Imagine the machine just as series of switches (which they are) so that you don't get confused into thinking that a computer has this magnificent brain of its own.

Start with a simple program (say C) like "hello world". I don't think a newbie should jump straight into an object oriented platform. Once you have familiarize yourself with the basics, it will be easy to learn other languages.

[asthmatic camel]

Millenium hand and shrimp. I told 'em it's an unusual person who becomes a successful programmer.

My dear friend, Nick the Ninja, can spend 24 hours writing programs without a break; I can't stick with it for 24 seconds before the tedium becomes unbearable. He's rule8ing useless at everything else!

[Zep]

Ask me how! That's how I started in this silly IT game - programming for a living.

[RyanRoberts]

Have you tried modding (if you are a gamer)? Quite a few non programmers enjoy game scripting.

[Oleron]

jm01 - Isn't C or Assembly fiendishly difficult to learn? I always kinda avoided these kind of languages.

AC - Buggr'em'all. I'll have to find a Nick the Ninja.

Zep - I'm askin!

I'm guessing that VB or a script-type language would actually be of most use to me? Any good advice on where to start?

[Oleron]

Have you tried modding (if you are a gamer)? Quite a few non programmers enjoy game scripting.

I've always avoided mods, being more of a rocker, really. ;)

I'm a bit out of touch with games these days.

[JamesM]

Do you want to program for a specific task or just as a hobby?

As you're a sysadmin maybe there are some existing scripts you could play around with, or some tasks that could do with automating. That would at least provide some motivation and a defined goal. Like anything, getting started is the hard bit.

[Jekyll]

When it comes to programming. I am fascinated by computer programming and have read many books on the subject. I have studied programming self-teach books on several languages - notably Java, C++ and VB. When I read them, I think I understand them but when it comes to actually 'writing a program' I take a complete mental blank and have no idea where to start.


Can you do the exercises in the books? You can't learn to program by just reading about it, you have to actually do it.

[logical muse]

I am (or was) a programmer, and I've taught computer programming at college.

In my experience, the people who had the most difficulty learning to program were those people whose idea of how a computer worked differed from reality. People who had absolutely no idea seemed to catch on easier. As an IT person, this may not apply to you, but give it a little thought.

A computer program is, at one level, a series of instructions written in a particular language. The language is quite specific, and is designed for an abstract machine (I'm not talking about various assembly languages). The instructions manipulate the state of the abstract machine.

This abstract machine may in fact be the data set of the program. As an example, let's say we have a machine that compares two numbers, and tells us which is the greater.

We need to label the numbers, because for the most part we won't be referring to them by their values. Kind of like putting each number in its own box and then referring to 'the number in box A' and 'the number in box B'.

Our program then looks something like:

If 'the number in box A' is greater than 'the number in box B'
Open box A and read the number out
Otherwise
Open box B and read the number out

I hope I'm not insulting your intelligence with such a trivial example, but your statement about 'a complete mental blank' makes me think that the problem you have relates to a fundamental issue of understanding what an abstract computing machine is.

It may help to play around with the kind of technique I demonstrated above. Here's another one. Let's say you want to determine how many days sylvia brown needs to work in order to buy a ferrari.

We need to write down what we know, the pertinent information.

Sylvia does readings. Each reading takes time. She can do a number of readings in a day. A ferrari has a price.

Let's figure out a formula, or algorithm.

We need to work out how many readings it will take to make up the cost of the Ferrari, and then work out how many days she has to work to do that many readings.

Here's our first formula:

Cost_of_ferrari / price_of_a_reading = number_of_required_readings

We're not programming yet, just working out our formulas.

Our next formula tells us how many readings she can do in a day:

Hours_in_a_work_day / duration_of_a_reading = number_of_readings_per_day

OK, we have our formulas. We could simplify things slightly by using constants. For example, a constant could be that her readings go for half an hour, and that this will never change, or that they cost $750 and that will never change, or that a Ferrari costs $200,000, and that will never change.

Alternatively, we can use variables (numbers in boxes), and the program will ask for the current value of those things.

Now, let's look at our language. It's a simple language for a simple computer. Our computer can only do a few things. It can display text on the screen. It can ask the user to type some information in, and it can do some simple calculations. It has a little memory, consisting of boxes that it can store numbers in. It can label the boxes.

Now we're ready to code!

What's our strategy?

We need the program to ask the user for some information; how much does a ferrari cost, how much does Sylvia charge, etc.

The program then has to do the calculations as per our formulae.

It then has to display the result.

The keywords of our language are:

GET, which flashes a little cursor and waits for the user to type something in.
DISPLAY, which displays some text on the screen
Any lines in our program that start with // are comments, the computer ignores the rest of the line, it's just for humans to read

Ok, here's our program:


DISPLAY "Hello, let's work out how long it will take Sylvia to earn enough money to buy a Ferrari."
DISPLAY "Tell me, how much is a Ferrari these days?"
// this next line gets a number from the user and stores it in a little box labelled 'ferrari_cost'
GET ferrari_cost
DISPLAY "Thanks, now tell me... How much does Sylvia charge for a reading?"
GET reading_cost
DISPLAY "OK, and how long (in hours) does a reading go for?"
GET reading_duration
DISPLAY "How many hours a day do you reckon she can work?"
GET hours_worked_per_day
DISPLAY "OK Thanks. Let me think for a minute"
// now let's use one of our formulas!
readings_per_day = hours_worked_per_day / reading_duration
// we stored the answer in a box labelled 'readings_per_day'
//
// ok now let's use the other formula
//
required_readings = ferrari_cost / reading_cost
number_of_days = required_readings / readings_per_day
//
// we can give this info to the user now
//
DISPLAY "Sylvia needs to do 'required_readings' in order to earn enough money to buy a Ferrari. At 'readings_per_day' readings per day, it will take her 'number_of_days' days to accomplish that."
// In the above instruction, the variable names in single quotes have their values displayed. It's like the DISPLAY instruction opens the boxes with those labels and reads the numbers out.
DISPLAY "Not bad, huh?"


Let's add some conditionals in there. These allow our program to choose which action to take based on certain criteria. To do this we need to add a couple of keywords to our language:

IF, which tests a condition to see if it's true or not, and indicates what to do if the condition is true
ELSE, which indicates what to do if the condition was false
ENDIF, which indicates that the program can go back to executign instructions in order.

Here's our updated program:


DISPLAY "Hello, let's work out how long it will take Sylvia to earn enough money to buy a Ferrari."
DISPLAY "Tell me, how much is a Ferrari these days?"
// this next line gets a number from the user and stores it in a little box labelled 'ferrari_cost'
GET ferrari_cost
IF ferrari_cost < 30000
DISPLAY "I said Ferrari, not Mazda"
ENDIF
DISPLAY "Thanks, now tell me... How much does Sylvia charge for a reading?"
GET reading_cost
IF reading_cost > 700
DISPLAY "Man, I'm in the wrong line of work"
ELSE
DISPLAY "I heard it was more than that"
ENDIF
DISPLAY "OK, and how long (in hours) does a reading go for?"
GET reading_duration
DISPLAY "How many hours a day do you reckon she can work?"
GET hours_worked_per_day
IF hours_worked_per_day > 8
DISPLAY "I somehow doubt that"
ENDIF
DISPLAY "OK Thanks. Let me think for a minute"
// now let's use one of our formulas!
readings_per_day = hours_worked_per_day / reading_duration
// we stored the answer in a box labelled 'readings_per_day'
//
// ok now let's use the other formula
//
required_readings = ferrari_cost / reading_cost
number_of_days = required_readings / readings_per_day
//
// we can give this info to the user now
//
DISPLAY "Sylvia needs to do 'required_readings' in order to earn enough money to buy a Ferrari. At 'readings_per_day' readings per day, it will take her 'number_of_days' days to accomplish that."
DISPLAY "Not bad, huh?"


And there you have it. You'll be writing Linux device drivers in no time. :)



PS There may be some errors! I apologise in advance...

[Oleron]

Do you want to program for a specific task or just as a hobby?

As you're a sysadmin maybe there are some existing scripts you could play around with, or some tasks that could do with automating. That would at least provide some motivation and a defined goal. Like anything, getting started is the hard bit.

I think programming for specific tasks is more the kind of thing I need to do. Regular stuff like running scripts that date checks a file on a users pc and updates it if neccessary. Or checks the contents of a text file for specific words or phrases.
More advanced stuff like logging data into a SQL database would be nice also. But I can't see me ever needing to write a full-fledged project.

Can you do the exercises in the books? You can't learn to program by just reading about it, you have to actually do it.

Well, yes and no! Many of the books I've read have been more reference than anything and the self-teach ones often start with a 'hello world' and at some point seem to leap ahead and lose me.
Then, when I decide on a project, I really don't know which language I should use and how it should be approached. Perhaps I'm confusing myself by looking at lots of languages in the hope that one of them will make sense to me!:boggled:

[Oleron]

I am (or was) a programmer, and I've taught computer programming at college.

In my experience, the people who had the most difficulty learning to program were those people whose idea of how a computer worked differed from reality. People who had absolutely no idea seemed to catch on easier. As an IT person, this may not apply to you, but give it a little thought.



I approach learning a new subject in a scatterbrained way. I tend to jump from topic to topic, absorbing a little in every area, until I have a moment of revelation where the framework for learning becomes clear. This works well for me a lot of the time but fails utterly when learning to program. I need to be more focussed and concentrate on the task.

Your code makes perfect sense to me, all I need now is the compiler!

[JamesM]

I think programming for specific tasks is more the kind of thing I need to do. Regular stuff like running scripts that date checks a file on a users pc and updates it if neccessary. Or checks the contents of a text file for specific words or phrases.
More advanced stuff like logging data into a SQL database would be nice also. But I can't see me ever needing to write a full-fledged project.
For these tasks, I would recommend a scripting language. Any sort of Unix box will have Perl preinstalled, so that might be a good place to start.

Perl's syntax is ugly and often cryptic, but there are lots of books about on it and it's well suited to simple scripting - particularly reading and writing text files, which is basically Perl's raison d'etre. There are also plenty of books out there. O'Reilly's Learning Perl is perfectly serviceable for this purpose. It's fairly short and you can pick it up cheaply.

[Nick Bogaerts]

I started learning programming with AmigaBASIC. BASIC is a little dated by now, but I think is still the best language tailored for beginners.

Only after that did I move onto C, which is probably necessary to get more of a 'behind the scene' view of computers. Scripting languages tend to hide a lot of what is happening, which I don't think is a good thing when you are learning, so I'd leave those to later.

[JamesM]

Only after that did I move onto C, which is probably necessary to get more of a 'behind the scene' view of computers. Scripting languages tend to hide a lot of what is happening, which I don't think is a good thing when you are learning, so I'd leave those to later.
I don't think is good advice for someone who wants to get into programming. They should be taught the how, before the why.

The whole point of programming a computer is to get stuff done. The more a programming language hides what's happening under the hood, the better. The low level paraphenalia that C provides is a complete distraction from what's important: manipulating whatever it is you want to model at the correct level of abstraction.

Want to tell someone how to make a cup of tea? You start by telling them to put some water in the kettle and boil it. You don't talk about the wavefunctions of the electrons in the water molecules. You hide that complexity under the abstraction of 'water'.

Likewise, want to open a file and read its contents? Then deal with filenames and text, not arrays of pointers to characters and file handles. Obviously, for some purposes, not hiding what's happening is the point of the exercise. That's what makes the likes of C so useful for programming operating systems and device drivers. But those tasks are an extremely small proportion of what a program can do.

[jimlintott]

I only program as a hobby and then it is usually pretty simple stuff. Back in 1975 the high school I attended offered Computer Science which I took. We had an excellent teacher who was able to conceptualise programming for us. We used Fortran (on punch cards) and looked at machine code. The teacher used a psuedo code thing that got us the concept.

Later I would program in MS Basic on my Tandy CoCoII (16k of RAM, baby). After getting a 8086 I used GWbasic but was lucky enough to take on a little offer from a Texas company that sold a C compiler with a great book for $20. I indulged in that book and used C on that computer for many years.

When I started using Linux (about '97, '98) I was able to dig up that old C book and use it again. I started using PERL for lots of scripting. If any new programming projects pop up I may try Python. It seems popular.

I don't think the language is all that important. What is important is taking input, generating output, doing lots of little things over and over again and knowing when to stop. I've always found the hardest part of programming is coming up with something I need to program. Without a purpose or problem to solve you'll just get another "Hello World".

I find it fun but I don't know if it would be fun if it was my full time job.

[Nick Bogaerts]

I don't think is good advice for someone who wants to get into programming. They should be taught the how, before the why.

The whole point of programming a computer is to get stuff done. The more a programming language hides what's happening under the hood, the better. The low level paraphenalia that C provides is a complete distraction from what's important: manipulating whatever it is you want to model at the correct level of abstraction.

A programmer needs to know two things: how to find the solution to a problem, and how to select the right tool.

I've never had to implement TreeSort in Reverse Polish Lisp, but I wouldn't be much of a programmer if I didn't know how to sort records, and how to use a functional language.

Want to tell someone how to make a cup of tea? You start by telling them to put some water in the kettle and boil it. You don't talk about the wavefunctions of the electrons in the water molecules. You hide that complexity under the abstraction of 'water'.

And I haven't started by explaining how a transistor works. I start with the difference between a tea kettle and a coffee pot.

[RyanRoberts]

If you admin windows boxes, you might want to have a look at Monad/Powershell (http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx). It's an actual Microsoft innovation (at least when compared to the UNIX world) - a powerful object oriented programmable shell. It also takes the "everything as a file" UNIX metaphor to heart and allows you to mount, navigate and update the registry, active directory etc as if they were a file system.

The whole thing reminds me vaguely of my (pretty limited) experience of VMS, what with the command naming scheme. It's a hell of a step away from batch files and vbscript admin.

[RSLancastr]

Oleron:

I've found that the best way to learn a language is to fiddle aruond with a program which has already been written:

1. Find the code for an existing program (hopefully a relatively small and simple one).
2. Study the code a bit to try and understand a bit about how it works.
3. Try to make a simple modifications to it.
4. Try to make another simple modifications to it.

... and you're off!

I don't know if others would agree with this but this is based on my experience.

When I first started to learn programming (COBOL), my brother had an S/370 Assembly language book. Learning the most basic about computers had helped me a lot to learn the language. I was programming in 3 weeks time.I've programmed for a living for 30 years, and have never learned assembler. Not only is it not necessary, but could quite well scare off a newbie.

Once, about fifteen years ago, I decided I should learn assembler, and bought a book on beginning assembler.

After going through four chapters before I could write a program which simply displayed an asterisk on the screen, I said "life is too short for this crap."

Maybe learning assembler is a young person's thing. Only they would have the time for it...

I suggest that you familiarize yourself with binary arithmetic and boolean arithmetic.Again, I've coded for 30 years, and I don't even know the difference between the two.

[JamesM]

I've never had to implement TreeSort in Reverse Polish Lisp, but I wouldn't be much of a programmer if I didn't know how to sort records, and how to use a functional language.
A 'functional' language? When someone says 'functional' I think of the likes of Haskell and ML, or semi-functional languages like Common Lisp and Scheme. Do you mean them? If so, I can't agree that it's vital to know Haskell to be 'much of' a programmer.

As for sorting, any modern language provides sort routines as part of their libraries. I've done plenty of sorting in several languages. In each case, I used the existing sort routines, and everything was a-ok, leaving me to focus my remaining brain cells on more interesting problems. I can see how knowing the various sort algorithms is intellectually stimulating, and in the grander scheme of things, excellent training in algorithmic thinking, but I've never felt the need to write my own sort routines.

I mean, I do agree that programmers should know about algorithms and their relative time and space requirements, but it's quite a long way down the list of priorities for a beginner.

I hasten to add that I'm not putting myself forward as an example of a good programmer, I'm just saying you can get a long way without knowing much detail about these things, and it's positively harmful to think you have to learn the nuts and bolts up front. I'm sure it's different if your job description is software engineer or you're a computer scientist. But I program every day as part of my work, and I'm neither of those things.

[logical muse]

I approach learning a new subject in a scatterbrained way. I tend to jump from topic to topic, absorbing a little in every area, until I have a moment of revelation where the framework for learning becomes clear. This works well for me a lot of the time but fails utterly when learning to program. I need to be more focussed and concentrate on the task.

Your code makes perfect sense to me, all I need now is the compiler!

Hey Oleron,

I think a language like BASIC may be useful to you. My pseudocode in that example is a lot like it.

You really need to be able to develop a mental model of your programming problems (I mean, tasks) in terms of the abstract computing machine.

Good luck!

[SpeederA]

If you're having problems trying to figure out where to start, I would recommend looking for repetitive tasks you tend to do once an hour/day/week while at work. Those that take up a significant amount of time (e.g. More than 10 minutes) are a good place to start.

For example, say you have three services that store data. Now, these three services lock access to the files they use and, for some reason or other, have no online backup capability. Being the good sysadmin you are, ;) , you dutifully stop the services once a day, copy the files to a folder called Backup and rename them in the format "MM_DD_YYYY FileType". Then you restart the services and all is well with the world.

One day you think to yourself: "Hmmmm, this repetitive task is getting boring and repetitive." "Wait, did I just say repetitive twice? I'm so silly. hehe". oh, whoops. That's what I would say to myself. :D

Here's what you would think: "Hmmm, this repetitive task doesn't change much each time I do it. How could I get the computer to do this automatically for me?"

"Let's see"

"First thing I've gotta do is stop those services."
"I can do that easily with Net Stop."

"Okay, so the first lines of my program will be this:"

Shell "Net Stop Service1"
Shell "Net Stop Service2"
Shell "Net Stop Service3"

"What's next?"
"Copy and rename the files!"

File.Copy("C:\DataFiles\Service1.wee", "C:\Backups\10_25_06 Service1.bak")

File.Copy("C:\DataFiles\Service2.wee", "C:\Backups\10_25_06 Service2.bak")

File.Copy("C:\DataFiles\Service3.wee", "C:\Backups\10_25_06 Service3.bak")

"Okie. This is looking good!"
"Whaddaya expect from a handsome, smart, intelligent person such as myself. ;)"

"Now to turn back on the services."

Shell "Net Start Service1"
Shell "Net Start Service2"
Shell "Net Start Service3"

"Awesome. Now all I have to do is change the date every time I run my program. But wait. I have to do that three times. Blah. I'm way too lazy for that."

"Let's try this..."

Dim backupDate as String = "10_25_06"

File.Copy("C:\DataFiles\Service1.wee", "C:\Backups\" & backupDate & " Service1.bak")

File.Copy("C:\DataFiles\Service2.wee", "C:\Backups\" & backupDate & " Service2.bak")

File.Copy("C:\DataFiles\Service3.wee", "C:\Backups\" & backupDate & " Service3.bak")

"Awesome. Now I only have to do it once. Hmmm.... Anyway I could make this even better? What if the computer could write in the date for me?!?!"

Dim backupDate as String = Today.ToString("MM_dd_yyyy")

"Woo hoo! Nothing to do now but relax and drink pina coladas!" :D

'-----------------
Dim backupDate as String = Today.ToString("MM_dd_yyyy")

Shell "Net Stop Service1"
Shell "Net Stop Service2"
Shell "Net Stop Service3"

File.Copy("C:\DataFiles\Service1.wee", "C:\Backups\" & backupDate & " Service1.bak")

File.Copy("C:\DataFiles\Service2.wee", "C:\Backups\" & backupDate & " Service2.bak")

File.Copy("C:\DataFiles\Service3.wee", "C:\Backups\" & backupDate & " Service3.bak")

Shell "Net Start Service1"
Shell "Net Start Service2"
Shell "Net Start Service3"
'-----------------

So here's the trick to simple scripting.

1. Find a task that you do manually.
2. Write out that EXACT same task in the simplest code you can manage.
3. Find out which parts always stay the same and which change.
4. Put the parts that change into variables (Containers for data).

Voila you have now subjugated your computer and can rule over it with a firm, yet gentle, hand. ;)

After you've got that down, you can start making more complex scripts using logical statements. The joke is that you write those in the exact same way you think as well. Programming becomes easy when you realize that all you have to do is solve the problem in code the exact same way you solve it in your head.

Next week, "Encryption Made Easy!". Find out what's so fascinating about prime numbers and how you can make them your bitch. :D

[Paul C. Anagnostopoulos]

The whole point of programming a computer is to get stuff done. The more a programming language hides what's happening under the hood, the better. The low level paraphenalia that C provides is a complete distraction from what's important: manipulating whatever it is you want to model at the correct level of abstraction.
But the problem is that programming language books mostly suck at teaching the abstractions that are embodied in the language. And this is particularly true for modern programming languages such as Perl, where Wald thinks the best way to learn a language is to learn a pile of syntactic hacks and their associated arbitrary semantics (witness the sigils). Apparently this sort of language learning works for many people, just as the "whole language" approach often works for learning reading, but a large number of people are just befuddled.

On the other hand, when you learn assembly language or low-level C, you're forced to learn the abstractions, because that's all there is and they are relatively simple. I'm not suggesting we all go back to assembly language, mind you.


I've found that the best way to learn a language is to fiddle aruond with a program which has already been written
That is a good suggestion.


I've programmed for a living for 30 years, and have never learned assembler.
I've been programming for 40 years, so you just missed the boat. :D


Again, I've coded for 30 years, and I don't even know the difference between the two [binary arithmetic and boolean arithmetic].
Are you sure? You're not one of these programmers who never uses a boolean expression, are you? You don't code 'if a == true then ...", do you? :D

~~ Paul

[RSLancastr]

I've been programming for 40 years, so you just missed the boat. :DI never programmed using a patch panel either. :D

Are you sure? You're not one of these programmers who never uses a boolean expression, are you? You don't code 'if a == true then ...", do you? :DHeyyyy!!!

Boolean logic I use all the time.

But the only time I ever did math with binary numbers was in programming school in 1976 or so. It was in a class which shuld have been titled "things you'll never have to do again."

[Paul C. Anagnostopoulos]

Boolean logic I use all the time.
I think that's what Jmonte meant. Whew, I was worried there for a moment.

~~ Paul

[RSLancastr]

I think that's what Jmonte meant.I hope so. I Googled "boolean arithmetic" and got loads of conflicting pages.

Here is one which rivals the TIME CUBE page...

Boolean Arithmetic And Linguistics' HOME PAGE (http://www.poli.usp.br/pea5737/01_ing.htm)

[logical muse]

It's all PDFs.

* sighs *

[a_unique_person]

I don't really need to know how to program for my job, although scripting and manipulation of the Windows API would come in useful. It's the thought that I CAN'T program, no matter how hard I try, that bothers me. I see it as an intellectual challenge.


There's your first mistake, DATKS, Design at the keyboard syndrome. Before you can write a line of code, you have to have a mental picture of what you want to do, and how you can then do it.

First of all you have to understand what the languages are capable of, and how they do it. Most tutorials will give you a very brief overview of these things, but to get to the stage of being able to make any sort of real application takes at least a year of study to get to know enough to be able to do something meaningful. Of course there are the freaks out there who just take a look and go, but most of us are humans, and take a lot longer to get to the stage where you can achieve something significant. Toy applications that do something simple can be built quite quickly, but that's where you have to start.

Once you have the basic understanding of what tools the language gives you to get the job done, you can then work out how you want to use them to to take the data in you are working on, and where it is going to end up. If you are going to use a real engineering approach, you will document all the inputs, ouputs, data stores, and how the data moves between them, how it is manipulated, and then write the code to do it all.

However, to answer your basic question, first of all, spend some time learning one language, using one development tool and environment, then try to build some simple applications and see how the bits all connect with each other.

For example, you aren't going to be able to just sit down and write a game engine, database, operating system, or anything like that.

Now, what do you actually want to do with your programming knowledge? What did you see yourself being able to achieve with it? That would be the first place to start.

[blutoski]

Oleron:

I've found that the best way to learn a language is to fiddle aruond with a program which has already been written:

1. Find the code for an existing program (hopefully a relatively small and simple one).
2. Study the code a bit to try and understand a bit about how it works.
3. Try to make a simple modifications to it.
4. Try to make another simple modifications to it.

... and you're off!

I've programmed for a living for 30 years, and have never learned assembler. Not only is it not necessary, but could quite well scare off a newbie.

Once, about fifteen years ago, I decided I should learn assembler, and bought a book on beginning assembler.

After going through four chapters before I could write a program which simply displayed an asterisk on the screen, I said "life is too short for this crap."

Maybe learning assembler is a young person's thing. Only they would have the time for it...

Again, I've coded for 30 years, and I don't even know the difference between the two.


I'm going to second the suggestion to find an existing sample program that is *very* simple, and tinker with it. As your skills grow, you can add more sophistication. Choose a language with buckets of sample code, as per the first point above, so you can see lots of simple examples.

The second piece of the puzzle is to find a resource book that has a list of the functions or whatever for the langage in question, and keep it beside the mouse and expect to use if often to 'look things up'. In other words: learn by reverse-engineering examples with a reference book.

I would also choose a language that you can use at the drop of a hat, which means that you can use it on your own computer, or with a quick login. This is why I use perl myself (My machines are linux or Macs) but the above suggestions for that sophisticated dos shell sound appropriate for a Windows environment. The other reason I prefer perl as a learning language is that it's a scripting language. This means "instant gratification" - ie: no futzing with a compile. Edit, save, run... edit, save, run... I think a learner develops faster.

Lastly, have a simple project in mind, and when you think you've got to a comfortable point in your ability to tweak existing code, try to adapt one to your project.

[Oleron]

Hmmm, I'm having a look at this Powershell stuff that RyanRoberts suggested. Looks like it might do the business.

The task I have chosen is to design a simple software/hardware audit tool for a windows environment. It would be nice if the tool could populate a database table with this info from all my network clients but I might be over-reaching myself there! Generation of a text file from each client will suffice for now.

I know I could buy such a tool for a few quid but I would learn nothing that way.

[jmontecillo01]

jm01 - Isn't C or Assembly fiendishly difficult to learn? I always kinda avoided these kind of languages.

With regards to Assembly, I accept that it is quite a difficult language to learn. The reason I mentioned that is so that you will get a fair idea of how the CPU works.

Coming from the old school. Binary arithmetic is say 1001 + 0100. It is simple arithmetic only in binary. That would also include bit shifting. Boolean arithmetic is "or", "xor","and",.... Boolean logic is "if condition (or condition and condition) then statement else statement". Mind you, the industry could have invented new terms for those.

Knowledge of the CPU is very important when the machine throws up, you can examine/understand the memory dump. But of course, we have tools to do that for us. But what happens when there is a problem with the lowest layer (the machine code), what do we do.

The advantage in C is that there are only a few "reserve" words you have to understand. Most of the time, you'll just have to use linkable codes.

I also used Delphi for some projects that I did. What I like about Delphi (Pascal) is its strong typing. Also, it gives you a clear view of how messaging works. You can create your own message and receive/send it.

Some people might not agree with me. VB encourages bad programming habits. You can use a variable without first defining it. I am also againts the use of variants if it can be avoided.

I do not agree in the way the industry is heading. We create layers upon layers of code. I know a lot of programmers who doesn't have any idea how the lowest layer works (machine code). I am afraid that in the future, we will end up with codes that only a few can maintain.

I use to create operating system components for the mainframe. The maximum memory of 16M was sufficient to service thousands of users around the world. Now the hardware has to keep up with the software. But thats just me.

Anyway, before you can code, you'll need to define exactly what you want to achieve. If you don't have a target, you'll just end up staring at the screen.

[Blue Bubble]

Another old fart chiming in with tuppence worth of advice (started in 1969, Fortran IV and Algol 60 at school in Scotland). I did Computer Science at university and have done huge amounts in assembly language professionally (which I absolutely thoroughly enjoyed - developed complete database system, written in our own dialect of APL, the interpreter/compiler for which we wrote in ca. 3 million lines of IBM Assembler).

Here's my suggestion along similar lines to those that have recommended "tinkering" with existing programs.

Get a programmer colleague, whom you trust as being very good, to give you a reasonably large program (i.e. not completely Mickey Mouse), intentionally introduce a number of bugs, and give you the program to debug. This way, you'll need to start understanding pretty much every statement in the program in order to judge whether it's correct or not.

The language is not too critical; obviously, though, I don't think it would be appropriate to start with Algol 60. Ideally the colleague should choose a "cleanly"-coded program; you don't want to pick up bad habits straight away - you've plenty of time for them later ;)

At the end of the exercise, you've just ended up with your first template which you can then re-use and re-cycle.

[pauldmin]

Oleron:
I've found that the best way to learn a language is to fiddle aruond with a program which has already been written:


Second that..

Most of my projects start off with me copying some of the old code I had and then modifying it. If I had to start from scratch I would be thumbing through my text books most of the time.

I see learning a computer language very much like learning to speak a foreign language. You can read through as many text-books as you like, but being exposed to a native speaker and trying to convey your intentions will always be difficult.
The only way is to find a problem you want to solve and try to build up a solution yourself. You may need to copy existing code and adapt it, but eventually you will have enough knowledge to build code yourself.

This of course does not tackle issues like debugging and philosophies like bottom-up, top-down but these can come later.

I think the problem today is that most of the popular languages push you directly into event-driven object-oriented programming, which is not always intuitive for a first-time programmer.

[jmontecillo01]

I think the problem today is that most of the popular languages push you directly into event-driven object-oriented programming, which is not always intuitive for a first-time programmer.

I do agree. The event driven technology hides the fact that in reality, the machine works in a procedural manner. For a new person learning how to program, it becomes confusing when their routines are suddenly triggered from nowhere.

[Angus McPresley]

Are you sure?

True.

You're not one of these programmers who never uses a boolean expression, are you?

False.

You don't code 'if a == true then ...", do you? :D

True. No, false.

[Spindrift]

Do you want to program or do you want to be a programmer?

The two things are not the same. I can cook, but I'm not a chef.

If you just want to program things for your own enjoyment then I would get something like VisualBasic.net Express. It's free and there is a lot of example code out there.

If you want to be a professional programmer then take classes.

And as logical muse said, you will become a much better programmer if you really understand how a computer works. You may never use assembler in your professional life, but understanding it will help you.

And just so you know 60% of all programmers are not very good at it. This is an observation I've made over 20+ years of writing software, working in all kinds of companies from Fortune 100 to small start-ups to dealing with outsource "talent".

The whole point of professional programming is NOT just to get things done. It is to write clear, concise, efficient, maintainable and usable code. Making something work is only a part of it.

[SpeederA]

[quote=Spindrift;2041034]And just so you know 60% of all programmers are not very good at it. This is an observation I've made over 20+ years of writing software, working in all kinds of companies from Fortune 100 to small start-ups to dealing with outsource "talent".[quote]

I would say it's more like %80.
heh, but %78.645 of all statistics are made up.

[Wavicle]

jm01 - Isn't C or Assembly fiendishly difficult to learn? I always kinda avoided these kind of languages.


Assembly really is not difficult to learn. There are only about 100 atomic operations assembly can do, and they are for the most part context insensitive. It is, however, fiendishly difficult to get much done in assembly. It depends on how deep, and in what direction, your curiousity is. If you really want to know "how does software accomplish that?" you will need to know Assembly.

The type of work I do requires me to be fairly comfortable with assembly, however for 99% of the work out there, it is not necessary. Nowadays there is very little professional justification for being an ace assembly coder. If you do decide to start there (because you're just curious), make sure you start with good old MS-DOS (not Linux/Bash, not windows, not mac).

[SpeederA]

<sarcasm> But Steve Gibson says EVERYTHING should be written in assembly and everyone knows he's a coding god! </sarcasm>

lol

The thing about C (and C++) that tends to throw most people for a loop are pointers. Especially pointers to pointers. But once you get it, you get it.

As for assembly. None of my guys know assembly and I don't expect them to ever learn it for work. I learned it years, and years ago, but only employ it these days when I look at dissasembly and that's mostly for bugs. For optimization it's mostly useless when it comes to modern windows programming as you never know what the JITter will end up doing on a different system.....

[Nick Bogaerts]

Assembly really is not difficult to learn. There are only about 100 atomic operations assembly can do, and they are for the most part context insensitive.

I don't believe Assembler to be more difficult to learn, but certainly different from high level languages, and there's no justification for a beginner to try and learn both at the same time. The size of the instruction set is not the issue: RISC machines are in fact more difficult for a human (but easier for a compiler) than their CISC predecessors. The only Assembler I learnt was the Motorola 68k, since that was the processor my first computers used (Amiga 1000, Macintosh Classic). The only real assembler programs I've written were for my Texas Instruments TI-92 pocket calculator, fort which I simply had no choice. I've never bothered with x86 assembler, as I've never felt the need.

[Almo]

Here's my advice:

Choose a project to program. Preferably something incredibly simple. I recommend Tic-Tac-Toe, two-player with a GUI in Visual Basic. You'll have a "New Game" and a "Quit" menu item. 9 buttons for the board, and a little code to determine if someone has won, or if the game is over.

Once you do that, then you branch out. Like add an AI who moves randomly. Learn about arrays and try to program two-player Othello; its rules are simple, and the moves are simple.

:)

[jimlintott]

Here's my advice:

Choose a project to program. Preferably something incredibly simple. I recommend Tic-Tac-Toe, two-player with a GUI in Visual Basic. You'll have a "New Game" and a "Quit" menu item. 9 buttons for the board, and a little code to determine if someone has won, or if the game is over.

Once you do that, then you branch out. Like add an AI who moves randomly. Learn about arrays and try to program two-player Othello; its rules are simple, and the moves are simple.

:)

That's pretty good advice. I remember when I had finished the C tutorial that I wrote a Mankala game. It was just a playing board for two but it kept score and wouldn't allow cheating. While doing it I learned that I needed a debugger to help figure out what was wrong, (Uninitialized variables in C can have some strange values), and that without comments there is a very good chance you will not be able to read your own code. :eye-poppi

[Paul C. Anagnostopoulos]

You could also write a Sudoka solver, so you don't have to solve the tedious things by hand.

~~ Paul

[a_unique_person]

And just so you know 60% of all programmers are not very good at it. This is an observation I've made over 20+ years of writing software, working in all kinds of companies from Fortune 100 to small start-ups to dealing with outsource "talent".


As a member of that 60%, I would just like to point out that 30% are not good, 30% are competent, 30% are very good, and 10% are gifted.

[Paul C. Anagnostopoulos]

It all comes down to boundary cases. If you can make yourself think about the boundary cases, everything else falls into place.

It's boundary cases, I tell you!

~~ Paul

[a_unique_person]

That's the good thing about using a query to get your data, boundary cases, and picket fences, don't exist anymore.

"For each gooba in foo, where blart is less than 10, perform qwerty."

[kevin]

Pick a task you do frequently. Write down the steps you do to accomplish it. Program it. Don't assume the program will be done in time for the next time you have to do the task, so the "program it" step will be long.

For example one task I had to do frequently as a Windows sys admin was to create a spreadsheet of all members of a security group or mail group, including members from nested groups

I wrote down what I thought a program might need to do to accomplish that: connect to AD, lookup information in AD, recurse through AD, open a file, write to a file, close a file. Etc....

Then I learned how to do each of the tasks writing many little programs that did just a few parts at a time. Eventually I assembled all the pieces into a working program.

If you're a windows sys admin I would start with vbscript because it is available on most machines. And microsoft has tons of example code on doing most of this stuff.

[SpeederA]

I can't stress enough that you should stay away from VBA. Not only will you learn plenty of bad habits, in an inferior scripting language, most of what you learn will soon be useless as Microsoft is deprecating it in the near future.

I like the idea of PowerShell for sysadmin stuff but you might want to hold off on that until it's gone gold. VB.Net 2005 Express will probably be a good starter point for you. It's free, fairly powerful, and has a ridiculous number of snippets and sample projects available and you'll have no problem hacking together PowerShell scripts after you learn the basics of programming.

[imagineNoReligion]

[quote=Spindrift;2041034]And just so you know 60% of all programmers are not very good at it. This is an observation I've made over 20+ years of writing software, working in all kinds of companies from Fortune 100 to small start-ups to dealing with outsource "talent".[quote]

I would say it's more like %80.
heh, but %78.645 of all statistics are made up.

I don't know what the actual statistic would be, but when I worked as a consultant for IBM, I traveled to many different customer sites and it surprised me just how many programmers knew little beyond copy and paste.

That was 10 years ago though, perhaps things have improved since then. I've been rather isolated with my current position all these years, to have any feel for it.

[SpeederA]

[quote=SpeederA;2041240][quote=Spindrift;2041034]And just so you know 60% of all programmers are not very good at it. This is an observation I've made over 20+ years of writing software, working in all kinds of companies from Fortune 100 to small start-ups to dealing with outsource "talent".

I don't know what the actual statistic would be, but when I worked as a consultant for IBM, I traveled to many different customer sites and it surprised me just how many programmers knew little beyond copy and paste.

That was 10 years ago though, perhaps things have improved since then. I've been rather isolated with my current position all these years, to have any feel for it.

It hasn't...... :(

[Paul C. Anagnostopoulos]

That was 10 years ago though, perhaps things have improved since then. I've been rather isolated with my current position all these years, to have any feel for it.
No, things have gotten worse. Back in my day, we knew how to program. Then kids stopped learning assembly language and everything went to hell, by cracky!

~~ Paul

[SpeederA]

It went more like this....

"Holy Crap! It's the year 1999 and everyone is throwing money at you if you just say the word 'Internet'. I gotta quit my job as a fry assistant and gemme some o' that!" ;)

[Oleron]

Sorry about being a little slow on the replies but my sysadmin job is starting to take some downright liberties with my free time, causing me to neglect my internet posting. It is also cutting into the time I have for following up these excellent suggestions.

Rest assured though, I have taken on board the advice here and am following it up when I get the opportunity.
Cheers,
Oleron.