• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Programming blind spot.

Oleron

Muse
Joined
Feb 17, 2004
Messages
940
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"?
 
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.
 
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!
 
Ask me how! That's how I started in this silly IT game - programming for a living.
 
Have you tried modding (if you are a gamer)? Quite a few non programmers enjoy game scripting.
 
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?
 
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.
 
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.
 
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:

Code:
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:

Code:
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...
 
Last edited:
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:
 
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!
 
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.
 
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.
 
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.
 
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.
 
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.
 
If you admin windows boxes, you might want to have a look at Monad/Powershell. 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.
 
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.
 
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.
 

Back
Top Bottom